Modellkontextprotokoll (MCP) och anteckningar om implementering av MCP-server i Go

Långläsning om MCP-specifikationer och implementering i GO

Sidinnehåll

Här har vi en beskrivning av The Model Context Protocol (MCP), korta anteckningar om hur man implementerar en MCP-server i Go, inklusive meddelandestruktur och protokollspecificeringar.

Robots och MCP

Model Context Protocol (MCP) Översikt

Model Context Protocol (MCP) är ett öppet, standardiserat ramverk (introducerat av Anthropic i slutet av 2024) för att ansluta AI-språkmodeller till externa datakällor, verktyg och system. Dess mål är att lösa “N×M-integrationsproblemet” genom att erbjuda ett universellt gränssnitt för saker som att läsa filer, köra funktioner (verktyg) och använda kontextuella promptar över olika applikationer. MCP är inte ett proprietärt eller internt protokoll; det är en öppen standard med en officiell specifikation och öppen källkod referensimplementering. Faktum är att stora AI-leverantörer (inklusive OpenAI och Google DeepMind) meddelade stöd för MCP efter introduktionen, vilket understryker att det är avsett som en bredt antagen standard snarare än en lösning specifik för en leverantör.

MCP Syfte och Arkitektur

MCP syftar till att standardisera hur applikationer tillhandahåller kontext till LLMs – den analogi som ofta används är “en USB-C-port för AI-applikationer”. Genom att definiera ett gemensamt protokoll låter MCP AI-assistenter och verktyg smidigt gränssnitta med databaser, filsystem, API:er och andra resurser utan anpassade enskilda integreringar. Detta hjälper språkmodeller att generera mer relevanta, uppdaterade svar genom att ge dem säker åtkomst till de data de behöver.

Arkitektur: MCP följer en klient–server-modell med tydlig rolluppdelning:

  • MCP Host: Den föräldraapplikation (t.ex. en chattklient eller IDE) som hanterar anslutningar. Den innehåller en eller flera MCP-klienter (anslutningar).
  • MCP Client: En anslutningsinstans (inom värden) som etablerar en 1:1-session med en MCP-server. Klienten hanterar sessionens livscykel, rutter meddelanden och tillämpar eventuella användarbehörigheter eller säkerhetspolicys.
  • MCP Server: En lättviktstjänst som exponerar specifika funktioner (åtkomst till viss data eller funktioner) via MCP-protokollet. Varje server kan omsluta en datakälla (filer, DB, API, etc.) eller verktyg. Flera servrar kan köra parallellt, var och en som erbjuder olika integreringar.
  • Data Sources/Services: De faktiska resurserna som servrarna gränssnittar med – detta kan inkludera lokala filer och databaser eller fjärrtjänster (webb-API:er, SaaS-applikationer, etc.). MCP-servern agerar som en adapter till dessa resurser, vilket säkerställer att LLM endast får åtkomst till data genom det standardiserade protokollet.

Denna design är inspirerad av Language Server Protocol (LSP) från IDE-världen. Precis som LSP låter vilken redigerare som helst stödja vilket programspråk som helst via ett gemensamt protokoll, låter MCP vilken AI-applikation som helst ansluta till vilken data/verktygsintegrering som helst som talar MCP. Denna avkoppling innebär att AI-verktygsutvecklare kan skriva en MCP-server en gång och sedan ha den fungera med många AI-klienter, och att AI-applikationsutvecklare kan lägga till nya integreringar genom att enkelt koppla in en MCP-server, undvika anpassad integreringskod.

Protokoll och Meddelandestruktur

Kommunikation: MCP-kommunikation är byggd på bestående, tillståndsbaserade sessioner med JSON-RPC 2.0-meddelanden. Alla begäranden och svar följer JSON-RPCs format (med en "jsonrpc": "2.0"-fält, metodnamn, parametrar och korrelerande ID:n). Både klient och server kan skicka begäranden eller notifieringar, vilket möjliggör tvåvägskommunikation. En MCP-session börjar vanligtvis med en handskakning:

  • Klienten initierar med en initialize-begäran, föreslår en protokollversion och annonserar sina funktioner (vilka funktioner den stöder). Till exempel kan klienten ange att den kan hantera serverdrivna “samplings”-begäranden eller tillhandahålla vissa rötter för filåtkomst. Servern svarar med sin egen stödda protokollversion och funktioner, vilket avslutar vilka funktioner som är aktiverade för denna session (MCP använder ett förhandlingssystem för funktioner liknande valfria funktioner i LSP). Om kritiska funktioner eller versioner är oförenliga, avbryts anslutningen på ett smidigt sätt.
  • Efter överenskommelse skickar klienten en initialized-notifiering för att markera beredskap. Efter detta kan normala operationer fortsätta. Sessionen förblir öppen för en kontinuerlig utbyte av JSON-RPC-meddelanden tills ena sidan utfärdar ett nedläggande.

Transporter: MCP föreskriver inte en enda transport – det fungerar över vilket kanal som helst som kan bära JSON-text. Vanligtvis körs en MCP-server som en underprocess och kommunicerar över STDIO (stdin/stdout-rör) för lokala integreringar. Detta är analogt med hur språkservrar fungerar och är bekvämt för lokala verktyg (värden kan starta serverprocessen och pipa meddelanden). Alternativt kan MCP-servrar köras som oberoende tjänster tillgängliga via HTTP. MCP-specifikationen definierar en strömmande HTTP-transport där servern exponerar en enda HTTP-ändpunkt för JSON-RPC-anrop (klienter POST-ar begäranden, och servern kan svara eller strömma resultat via Server-Sent Events för långvariga operationer). I vilket fall som helst är meddelandena UTF-8 JSON-rader, och protokollet stöder strömmande svar och serverinitierade meddelanden (HTTP+SSE-tillvägagångssättet låter servern skicka notifieringar eller delresultat asynkront). Säkerhetsriktlinjer rekommenderar att lokala servrar binder till localhost och validerar Origin-rubriker för att förhindra oönskad fjärråtkomst, och att rätt autentisering (t.ex. tokens eller OAuth-flöden) används för fjärrservrar.

Meddelandeformat: MCP utnyttjar JSON-RPCs tre meddelandetyp: Begäranden, Svar och Notifieringar. En begäran innehåller ett id, en method-sträng och (valfritt) params (vanligtvis ett JSON-objekt med argument). Mottagaren måste svara med ett motsvarande svar (med matchande id) som innehåller antingen ett result eller ett error-objekt. Notifieringar är som envägameddelanden med en method och params men inget id (så de får inget svar). MCP påtvingar några regler ovanpå grundläggande JSON-RPC (t.ex. id måste vara icke-noll och inte återanvändas under en session) för att upprätthålla klarhet.

Session och tillstånd: Anslutningen betraktas som tillståndsbaserad – klienten och servern upprätthåller kontext om varandras funktioner och eventuellt något sessionstillstånd (t.ex. prenumerationer på ändringar, pågående operationer, etc.). Det finns också definierade procedurer för smidig nedläggning (t.ex. kan en klient skicka en nedläggningsbegäran eller enkelt stänga transporten; servrarna bör hantera rensning, och båda sidorna implementerar tidsgränser för hängande operationer). Felhantering följer JSON-RPC-konventioner (felsvar har en kod och meddelande) och specifikationen definierar standardfelkoder för vissa tillstånd (t.ex. åtkomst nekad, verktyg inte hittat, etc.). MCP erbjuder också verktyg för tvärsnittsfrågor: till exempel finns det inbyggda notifieringar för framstegsuppdateringar, avbrytande av en långvarig begäran (CancelledNotification), logg/debug-meddelanden och konfigurationer. Dessa hjälper till att hantera långa eller komplexa interaktioner (klienten kan avbryta en pågående verktygsanrop, eller servern kan logga varningar till klienten, etc.).

MCP Features and Operations

När en MCP-session har initierats, möjliggör den utbyte av kontext och kommandon på ett strukturerat sätt. De centrala server-sidiga funktionerna är Prompts, Resources och Tools (var och en av vilka servern deklarerar om den stöder under initialiseringen):

  • Prompts: Fördefinierade promptmallar eller instruktioner som servern kan tillhandahålla för klienten. Dessa är vanligtvis användarutlösade hjälpmedel (användaren väljer explicit en prompt för att infoga i konversationen, t.ex. via ett snedstreckskommandon i gränssnittet). MCP tillhandahåller metoder för att lista tillgängliga prompts och hämta en prompts innehåll. Till exempel kan en klient anropa prompts/list för att få en lista över promptmallar (var och en med ett namn, beskrivning och valfria parametrar). För att hämta en prompt använder klienten prompts/get med promptens namn och eventuella argumentvärden; servern returnerar då promptens innehåll (ofta som en eller flera meddelanden som klienten kommer att injicera i LLMs kontext). Prompts möjliggör återanvändning av komplexa instruktioner eller arbetsflöden (t.ex. “kodgranskningsmall”) som en användare kan aktivera på begäran. Servrar indikerar en prompts-förmåga (med valfria underfunktioner som listChanged för att meddela klienten om promptuppsättningen ändras dynamiskt).

  • Resources: Strukturerad data eller innehåll som ger kontext till modellen. Resources är vanligtvis saker som filer, dokument, databasposter - information som en AI-assistent kan läsa eller referera till. MCP standardiserar hur resources identifieras och överförs: varje resurs har en URI-identifierare (t.ex. file:///path/to/file.txt eller ett anpassat schema för databaser). Klienter kan fråga vilka resources som är tillgängliga via resources/list (servern kan exponera en katalogstruktur, en lista över nyligen dokument, etc.). Serverns svar innehåller metadata för varje resurs (URI, namn, typ, beskrivning, etc.). Därefter kan klienten begära innehållet för en specifik resurs med resources/read, genom att skicka URI:n. Servern svarar med resursens innehåll, vilket kan vara text (för filer) eller strukturerad data (MCP stöder olika innehållstyper, som text, JSON, binärt, etc., med MIME-typer). Det finns också stöd för resursmallar (parameteriserade resources identifierade av mall-URIs, som klienten kan fylla i, t.ex. en databasfråga där användaren tillhandahåller en parameter). Om det är aktiverat, kan servrar skicka notifikationer när resources ändras (t.ex. notifications/resources/updated) eller låta klienter prenumerera på ändringar på en resurs (resources/subscribe). I MCP:s design är resources applikationskontrollerad kontext: den värdande applikationen (klienten) bestämmer vanligtvis vilket resursinnehåll som faktiskt matas in i modellens prompt (ofta efter användarbekräftelse eller baserat på UI-kontext).

  • Tools: Exekverbara funktioner eller åtgärder som servern exponerar för att modellen kan anropa. Tools representerar operationer som AI kan utföra - t.ex. anropa ett externt API, köra en databasfråga, skicka en e-post eller ändra en fil. Varje tool har ett namn och ett JSON-schema för dess inmatnings- (och eventuellt utmatnings-)parametrar, så att AI:n (eller klienten) vet vilka argument den förväntar sig. Tools är vanligtvis modellkontrollerade: idén är att språkmodellen (agenten) bestämmer om och när en tool ska användas under en konversation för att uppfylla användarens begäran. För säkerhet kan dock en människa eller värdapplikationen mediera tool-användningen (t.ex. kräva ett bekräftelseklick). Användning av tools i MCP involverar två huvudoperationer: lista och anropa. En klient kan anropa tools/list för att få tillgängliga tools och deras scheman. Till exempel kan en server lista en tool get_weather med en beskrivning och ett inmatningsschema som kräver en “location”-sträng. Därefter, när modellen bestämmer sig för att använda en tool (eller användaren aktiverar den), skickar klienten en tools/call-begäran med tools namnet och ett JSON-objekt med argument. Servern exekverar funktionen och returnerar resultatet, vanligtvis som ett result.content-fält som kan innehålla text eller strukturerad data (MCP stöder att returnera flera innehållsdelar, t.ex. text plus en bild, etc., även om text är vanligt). Ett enkelt exempel: att anropa en get_weather-tool kan returnera en textnod som “Aktuellt väder i New York: 72°F, delvis molnigt” som innehåll för assistenten att presentera. Tools kan också indikera fel (svaret har en isError-flagga eller ett felobjekt om något gick fel). Liknande prompts och resources kan tools-förmågan ha en valfri listChanged-flagga för att meddela när tillgängliga tools ändras under körning (t.ex. ett dynamiskt plugin laddas/avladdas).

Förutom ovanstående server-erbjudna funktioner definierar MCP också klient-erbjudna funktioner (förmågor som servrar kan utnyttja om klienten stöder dem). Dessa inkluderar Sampling, Roots och Elicitation:

  • Sampling låter en server begära att klienten (och dess LLM) utför modellinferens inom sessionen. Till exempel kan en server initiera ett LLM-anrop (kanske för att fortsätta en chain-of-thought eller sammanfatta något) genom att skicka en begäran som sampling/request - klienten skulle då fråga modellen och returnera resultatet. Detta möjliggör agentbeteenden där servern kan driva AI:n att assistera i sina egna deluppgifter. (Alla sådana åtgärder är underkastade användar godkännande och policy - t.ex. måste en användare kanske godkänna att en server triggar modellen för ytterligare frågor.)

  • Roots låter servern fråga om eller arbeta inom vissa tillåtna filsystem eller URI-roots. Klienten kan tillhandahålla en lista över “root”-kataloger/URIs som servern har tillåtelse att komma åt, via roots/list. Detta är en säkerhetsfunktion som säkerställer att servern känner till gränserna (t.ex. vilka katalogträd den kan läsa från).

  • Elicitation låter servern be klienten att få mer information från användaren om det behövs. Till exempel, om en tool saknar en saknad information som inte tillhandahölls, kan servern skicka en elicitation-begäran, som klienten (UI) skulle översätta till en användarfråga (“X-integreringen behöver din API-nyckel, vänligen ange den”). På så sätt kan servern interaktivt samla inmatning via klienten.

Dessa funktioner är alla valfria och förhandlas i förväg. En central designaspekt av MCP är att förmåganegotiation sker under initialiseringen - klienten och servern annonserar vilka av ovanstående funktioner de stöder, så att båda sidor vet vilka operationer som är tillgängliga i sessionen. Till exempel, om en server inte deklarerar tools-förmågan, kommer klienten inte att försöka med några tools/list eller tools/call-operationer med den. Denna utbyggbarhet innebär att MCP kan utvecklas med nya funktioner över tid samtidigt som bakåtkompatibilitet bibehålls (icke-stödda metoder kommer helt enkelt inte att användas om de inte förhandlats).

Implementeringar, SDK:er och byggande av en MCP-server (särskilt i Go)

Officiell specifikation och dokumentation: Den auktoritativa MCP-specifikationen är öppen tillgänglig, inklusive ett formellt schema för alla meddelandetyp. Den underhålls på Model Context Protocol-websidan och GitHub. Specifikationen är definierad i en TypeScript-schemalfil (med en motsvarande JSON Schema) som precist dokumenterar alla begäranden, svar och strukturer. Dokumentationssidan (modelcontextprotocol.io) erbjuder guider, en FAQ och detaljerade beskrivningar av varje funktion och meddelandetyp, samt ett verktyg “MCP Inspector” för interaktiv felsökning. Även om MCP inte (ännu) är en IETF- eller ISO-standard, utvecklas det som en öppen standard med community-input och använder bekant RFC 2119-terminologi för krav. Det är ett utvecklande protokoll (versioner är datumstämplade; t.ex. 2025-06-18 är en senaste revision), med en versionspolicy för att hantera ändringar.

Referensimplementeringar: Anthropic öppnade källkoden för ett antal MCP-serveranslutningar och SDK:er när de introducerade MCP. Det finns en GitHub-organisation modelcontextprotocol som värdar specifikationen och flera repository. Noterbart innehåller ett “servers” repository en samling förbyggda MCP-serverimplementeringar för vanliga tjänster och datakällor. Dessa tjänar som referensintegrationer och kan ofta användas direkt eller som mallar för anpassade servrar. Till exempel innehåller den officiella repo servrar för Google Drive (filåtkomst och sökning i Google Drive), Slack (arbetsplatsmeddelanden och kanalinnehåll), GitHub/Git (kodförvarskontext), PostgreSQL (skrivskyddade databasfrågor med schemainfo), Google Maps (plats- och riktnings-API), Puppeteer (webbläsning och skrapning), och många fler. Genom att installera eller köra dessa servrar kan en AI-applikation som Claude eller Cursor omedelbart få den integrationen. Det finns också en community-driven MCP registretjänst (öppen källkod i Go) för att indexera tillgängliga servrar, och många tredjepartssbidrag som utökar MCP till olika domäner (från CRM till blockkedjedata).

SDK:er och bibliotek: För att underlätta byggande av egna MCP-servrar/klienter finns det officiella SDK:er på flera språk. Från och med 2025 erbjuder projektet SDK:er för TypeScript/Node, Python, Java (och Kotlin), C# (utvecklad med Microsoft), Ruby (med Shopify), Swift, och andra. Dessa bibliotek hanterar protokollplumbing - t.ex. hanterar JSON-RPC-transporten, implementerar specifikationsschemat och erbjuder hjälp-API:er för att registrera verktyg eller servera resurser. Till exempel kan TypeScript-SDK:en användas för att snabbt skriva en server i Node.js, och Python-SDK:en låter integrera MCP i Python-applikationer. SDK-tillvägagångssättet innebär att utvecklare inte behöver manuellt konstruera JSON-RPC-meddelanden eller implementera hela tillståndsmaskinen; i stället anropar de högre nivåers metoder för att skicka begäranden eller publicera kapaciteter.

Go-implementering: Go har blivit ett populärt val för MCP-servrar på grund av dess prestanda och konkurrensförmåga (bra för att hantera flera samtidiga begäranden). En officiell Go-SDK finns nu tillgänglig, underhållen i samarbete med Go-teamet på Google. (Detta meddelades omkring april 2025 och den första stabila versionen är planerad för augusti 2025.) Go-SDK:en erbjuder ett paket mcp för att bygga klienter/servrar och en jsonschema-hjälp för verktygsscheman. Med Go-SDK:en kan utvecklare skapa en MCP-server med bara några anrop. Till exempel kan du instansiera en ny server med ett namn och version, sedan lägga till verktyg via AddTool genom att tillhandahålla en verktygsdefinition (namn, beskrivning, inputschema) tillsammans med en Go-handlersfunktion att köra när det verktyget anropas. SDK:en tar hand om att exponera verktyget i protokollet (annonsera det i tools/list och hantera tools/call-begäranden). Liknande kan du exponera resurser eller prompts med analoga API:er. Slutligen kör du servern - till exempel server.Run(ctx, mcp.NewStdioTransport()) kommer att starta bearbetning av JSON-RPC-meddelanden över stdio tills klienten kopplar ifrån. På klientsidan kan Go-SDK:en starta en underprocess och ansluta via mcp.NewCommandTransport(exec.Command("myserver")), sedan kan klienten anropa session.CallTool(ctx, params) för att anropa ett verktyg och enkelt få resultatet i Go-kod.

Exempel: Den officiella Go-SDK-dokumentationen visar en enkel “hälsningsserver”. Servern registrerar ett verktyg "hälsa" som tar ett namn och returnerar en hälsningstext. Klienten anropar sedan detta verktyg genom namn och skriver ut resultatet. Detta illustrerar det grundläggande mönstret: definiera verktyg -> klient anropar verktyg -> få resultat. Under ytan motsvarar detta JSON-RPC-meddelanden ("method": "tools/call", params: {"name": "hälsa", ...} och svaret innehåller result.content med text) som definieras av MCP-specifikationen.

Innan den officiella Go-SDK:en släpptes skapade community egna Go-bibliotek. Noterbart var Ed Zyndas mcp-go projekt (mark3labs/mcp-go) mycket använd och påverkade designen av den officiella SDK:en. Ett annat bibliotek, mcp-golang av Metoro, erbjöd en Go-implementering och API (Dev community bloggposten av Elton Minetto använder detta bibliotek från början av 2025). Dessa community-SDK:er lät Go-utvecklare experimentera med MCP tidigt - till exempel visar en tutorial hur man bygger en MCP-server som söker upp brasilianska postnummer (CEP) genom att exponera ett “postnummer”-verktyg via Metoros mcp-golang-bibliotek. I det exemplet registrerar Go-servern en funktion som anropar ett externt API för att hitta en adress från ett postnummer, och returnerar resultatet som text - vilket låter en AI-assistent hämta adressinformation på begäran genom MCP. En annan guide demonstrerar hur man paketerar en anpassad minnesdatabas (DiceDB) som en MCP-server med hjälp av mark3labs mcp-go SDK: den definierar ett ping-verktyg för att kontrollera DB-anslutningen och andra verktyg för dataoperationer. Dessa exempel visar hur enkelt det kan vara att skapa en MCP-integration: mestadels är koden bara affärslogik (API-anrop, DB-frågor etc.), medan SDK:en hanterar JSON-RPC-kopplingen.

Byggande av en MCP-server i Go (Tutorial-highlights)

För att beskriva processen, här är ett typiskt flöde med Go SDK eller liknande bibliotek:

  1. Serverinställning: Initiera en ny serverinstans med grundläggande info (namn, version och deklarera stöd för kapaciteter). Till exempel i Go: server := mcp.NewServer("MyServer", "1.0.0", nil) kommer att skapa en server som (som standard) stöder kärnprotokollfunktioner. Du kan aktivera specifika kapaciteter som prompts/resurser/verktyg via alternativ eller enkelt genom att registrera dessa funktioner (att lägga till ett verktyg eller resurs innebär den kapaciteten).

  2. Registrera funktioner: Lägg till de funktioner du vill exponera:

    • Om du exponerar Verktyg, definiera varje verktygs schema och handler. T.ex. med Go SDK:s AddTool: tillhandahålla en mcp.Tool{Name: "...", Description: "..."} och en handler-funktion som tar anropet och returnerar ett resultat (som kan innehålla text eller annat innehåll). SDK:en kommer att generera ett JSON Schema för input automatiskt från dina handlers parametertyper (eller du kan specificera det).
    • Om du exponerar Resurser, kan du använda ett API för att registrera resurslistor eller en callback för att läsa innehåll. I Python SDK:en, till exempel, kan du underklassa en ResourceProvider; i Go är SDK:en fortfarande under utveckling, men du skulle troligen tillhandahålla funktioner för att lista och läsa resurser. Varje resurs bör ha en stabil URI.
    • Om du exponerar Prompts, definiera promptmallar (kan vara statiska filer eller strängar) och registrera dem med namn och valfria parametrar. Servern kommer att annonsera dem så att klienten kan hämta och visa dem för användare.

  3. Implementera transport: Beslut hur servern ska köras. Enkelt för lokal användning är stdio - t.ex. server.Run(ctx, mcp.NewStdioTransport()) i Go kommer att starta läsning av JSON-RPC från stdin. Om din server ska vara nätverksansluten kan du implementera en HTTP-handler som använder Go SDK:en för att acceptera JSON-RPC över HTTP (den officiella Go SDK:en kan snart inkludera en hjälp för HTTP/SSE-transporten också).

  4. Klienttestning: Du kan testa servern med en MCP-kompatibel klient. Till exempel stöder Anthropics Claude 2 (Claude för Desktop) att ladda lokala MCP-servrar; du skulle konfigurera Claude för att starta eller ansluta till din serverbinär. Det finns också ett CLI-verktyg kallat mcp-cli och MCP Inspector-GUI för att testa servrar utan en fullständig AI-klient - dessa verktyg skickar MCP-begäranden till din server och visar resultaten, vilket hjälper med felsökning.

  5. Säkerhet och behörigheter: När du bygger en server, överväg autentisering och omfattning. För lokala servrar kan värden köra den med vissa OS-behörigheter eller tillhandahålla API-nycklar via miljö. För fjärrservrar, använd auth-headers eller OAuth-flöden. MCP inkluderar en auktoriseringsspecifikation för HTTP-transporter (servern kan kräva en token och klienten kan skicka den). Se alltid till att servern endast åtkommer data som användaren tillåtit (t.ex. respektera rotkatalogerna som tillhandahålls av klienten, och läck inte data någon annanstans) - MCP-riktlinjerna betonar användarens samtycke, datasekretess och verktygssäkerhet som grundläggande.

Sammanfattningsvis är MCP ett formellt men flexibelt protokoll för att koppla samman LLMs med den yttre världen. Det är inte ett internt API bundet till ett företag, utan en öppen standard med växande antagande och ett rikt ekosystem av integrationer. Protokollet definierar klara meddelandestrukturer (baserade på JSON-RPC) och en uppsättning operationer (metoder för prompts, verktyg, resurser etc.) som någon överensstämmande klient/server kan implementera. Officiell dokumentation och specifikationer är tillgängliga, och många SDK:er, bibliotek och exempelservrar (inklusive i Go) gör det enklare att implementera. Genom att använda MCP kan utvecklare bygga AI-drivna applikationer som säkert utnyttjar befintliga data och tjänster, utan att återuppfinna integrationslogik för varje ny modell eller datamängd.

Användbara länkar