En MCP-server är inte ert API med ny etikett

Demon gick bra. Någon kopplade en MCPModel Context Protocol (MCP)Model Context Protocol (MCP) är en öppen standard som låter AI-assistenter och agenter ansluta till verktyg, databaser, dokument och interna system på ett strukturerat sätt — så att AI:n kan agera i er verkliga miljö, inte bara svara generellt.Läs mer i ordlistan →-server mot ärendesystemet, ställde en fråga i chatten och fick ett svar byggt på riktiga data. Två veckor senare ser det annorlunda ut: assistenten väljer fel verktyg, hämtar hela kundlistan för att hitta en enda kund, och ingen vågar slå på skrivrättigheterna. Servern fungerar. Den är bara byggd för fel användare.

MCP, Model Context Protocol, är en öppen standard för att ge AI-assistenter och agenter tillgång till verktyg och data. Det gör det frestande enkelt att ta det API ni redan har och sätta en MCP-etikett på det. Men den som anropar är inte en utvecklare som läst dokumentationen. Det är en språkmodell som läser varje ord ni skrivit, tar dem bokstavligt — och aldrig frågar en kollega.

Vad en MCP-server faktiskt är#

En MCP-server erbjuder tre saker till den klient som ansluter — en chattassistent, en kodagent eller en funktion i er egen produkt:

• Verktyg. Handlingar modellen kan anropa: sök, hämta, skapa, uppdatera.
• Resurser. Data som klienten kan läsa in som kontext: dokument, poster, filer.
• Promptar. Färdiga mallar som användaren kan välja för återkommande uppgifter.

Servern kan köra lokalt på användarens dator eller som en tjänst över HTTP med inloggning. Protokollet är den enkla delen. Det svåra är vad ni väljer att exponera, och hur.

Verktyg ska motsvara uppgifter, inte endpoints#

Ett API är byggt för kod som vet exakt vad den vill. En modell resonerar sig fram, och varje steg den måste kedja ihop själv är en chans att gå fel:

• En uppgift, ett verktyg. ”Hitta kundens öppna ärenden” är ett verktyg. Tre anrop som modellen ska kombinera i rätt ordning är tre gissningar.
• Beskrivningen är gränssnittet. Modellen väljer verktyg utifrån namn och beskrivning. Skriv när verktyget ska användas — och vad det inte gör. Sanitys MCP-server, som vi själva använder för innehållet på den här webbplatsen, säger rakt ut i beskrivningen av verktyget som skapar en release att det inte schemalägger den. En mening, och ett felaktigt antagande mindre.
• Svaren kostar kontext. Allt servern returnerar hamnar i modellens arbetsminne. Ge den filter, sidindelning och möjlighet att välja fält — inte hela objektet varje gång.
• Felmeddelanden är instruktioner. ”400 Bad Request” lär modellen ingenting. ”Datumet ska anges som ÅÅÅÅ-MM-DD” gör att nästa försök lyckas.

Guardrails hör hemma i servern, inte i prompten#

En instruktion i en prompt är en önskan. En spärr i servern är en egenskap. Det som inte får hända ska inte gå att göra:

• Behörighet per användare. Servern ska agera som den inloggade användaren, med den användarens rättigheter — inte som ett servicekonto som ser allt.
• Läsa och skriva är olika verktyg. Då kan ni slå på läsning först och skrivning senare, och klienten kan kräva godkännande för just de verktyg som ändrar något.
• Skriv till ett utkast. I Sanitys server sparas ändringar som utkast, och att publicera är ett eget verktyg. Mellan modellen och det som blir publikt finns alltid ett uttryckligt steg.
• Innehåll är inte instruktioner. Text som servern hämtar ur ärenden, dokument och webbsidor kan innehålla uppmaningar riktade till modellen. Räkna med det när ni bestämmer vilka verktyg som får användas tillsammans.
• Logga varje anrop. Vem, vilket verktyg, vilka argument. Det är både er felsökning och er spårbarhet.

Där det brukar gå sönder#

1. Hela API:et, autogenererat. Varje endpoint blir ett verktyg. Modellen får en lång meny utan vägledning, och beskrivningarna är skrivna för utvecklare som redan kan domänen.
2. Verktyg som heter nästan samma sak. get_customer, customer_lookup och fetch_customer_info. En människa frågar vilket som gäller. Modellen väljer ett.
3. Servicekontot med full behörighet. Det snabbaste sättet att få demon att fungera, och det svåraste att backa från. Plötsligt kan alla som når assistenten läsa allt den når.
4. Ingen testar med en riktig modell. Enhetstester visar att verktyget fungerar. De visar inte att modellen väljer det, eller att den förstår svaret.

Så börjar du#

Börja inte med systemet. Börja med en fråga:

1. Välj en uppgift som folk i dag löser genom att fråga en kollega eller leta i tre flikar. Det är er första server.
2. Bygg en handfull läsverktyg för just den uppgiften. Inga skrivverktyg än.
3. Skriv namn och beskrivningar som dokumentation för en ny kollega som inte kan fråga — samma princip som i Er nästa plattformsanvändare är en agent.
4. Koppla in servern i en klient och kör riktiga uppgifter. Läs sedan loggen: vilka verktyg valdes, vad kom tillbaka, var gick det snett?
5. Lägg till skrivverktyg när läsningen sitter — ett i taget, mot utkast, med godkännande.

Det här är samma arbete som all produktutveckling: förstå användaren, bygg lite, se vad som händer, justera. Skillnaden är att användaren är en modell — och att den visar exakt var gränssnittet är otydligt, varje gång.

Vårt korta svar#

En MCP-server är ett gränssnitt för en användare som läser allt bokstavligt. Bygg verktyg kring uppgifter, skriv beskrivningarna som om de vore hela dokumentationen, och lägg spärrarna i servern. Då blir AI:n användbar i er verkliga miljö — och ni vågar låta den vara det.

Ett API med MCP-etikett ger er en demo. En server byggd för modellen ger er en funktion.