MCP eller API: när du ska använda MCP eller HTTP

När du kopplar en AI-agent till externa verktyg och API:er finns det två övergripande metoder: använd Model Context Protocol (MCP) som ett abstraktionslager, eller anropa ett API direkt över HTTP. Båda fungerar. De innebär olika avvägningar kring flexibilitet, komplexitet, prestanda och portabilitet.

Det här inlägget jämför de två metoderna med konkreta kodexempel, latensanalys och ett beslutsramverk för att välja mellan dem.

De två metoderna

Direkt HTTP-integration

AI-applikationen (eller dess backend) anropar externa API:er direkt med standardiserade HTTP-förfrågningar. Utvecklaren skriver kod för att konstruera förfrågningar, hantera autentisering, tolka svar och skicka tillbaka resultat till LLM:en.

┌────────────┐     ┌────────┐                         ┌────────────┐
│ Användare │────▶│ AI-app │──── HTTP-förfrågan ─────▶│ Väder-API  │
└────────────┘     │        │◀──── JSON-svar ─────────│            │
                   │        │                         └────────────┘
                   │        │── resultat som kontext ──▶ LLM
                   │        │◀── formaterat svar ──────
                   └───┬────┘
                       │
                       ▼
                 Användaren får svar

MCP-integration

AI-applikationen ansluter till en MCP-server som omsluter det externa API:et. Applikationen använder MCP-protokollet för att upptäcka tillgängliga verktyg, anropa dem med namn och ta emot resultat. MCP-servern hanterar de faktiska HTTP-anropen till det externa API:et.

┌────────────┐     ┌──────────────────┐              ┌────────────┐     ┌──────────┐
│ Användare │────▶│ AI-app/MCP-klient │── JSON-RPC ─▶│ MCP-server │────▶│ HTTP-API │
└────────────┘     │                  │◀─ JSON-RPC ──│            │◀────│          │
                   │                  │              └────────────┘     └──────────┘
                   │                  │── resultat som kontext ──▶ LLM
                   │                  │◀── formaterat svar ──────
                   └─────────┬────────┘
                             │
                             ▼
                       Användaren får svar

Den viktigaste skillnaden: med direkt HTTP äger AI-applikationen API-integrationskoden. Med MCP äger MCP-servern den, och AI-applikationen anropar bara verktyg med namn.

Du kan få MCP-sidan av det här diagrammet utan att bygga servern: Quickchat AI hostar en streamable-HTTP MCP-server för varje AI Agent, och att göra din agent till en MCP-server handlar om att klistra in en URL i AI-appen.

Kodjämförelse

Låt oss jämföra båda metoderna med ett praktiskt exempel: att hämta en GitHub-användares repositories.

Direkt HTTP-integration

import httpx

async def get_user_repos(username: str, token: str) -> list[dict]:
    """Hämta repositories för en GitHub-användare."""
    async with httpx.AsyncClient() as client:
        response = await client.get(
            f"https://api.github.com/users/{username}/repos",
            headers={
                "Authorization": f"Bearer {token}",
                "Accept": "application/vnd.github.v3+json",
                "X-GitHub-Api-Version": "2022-11-28"
            },
            params={"sort": "updated", "per_page": 10}
        )
        response.raise_for_status()
        repos = response.json()
        return [
            {
                "name": r["name"],
                "description": r["description"],
                "stars": r["stargazers_count"],
                "language": r["language"],
                "url": r["html_url"]
            }
            for r in repos
        ]

För att integrera detta med en LLM behöver du också:

• En verktygsdefinition i det format som LLM:en förväntar sig (OpenAI function calling-schema, Claude tool use-schema och liknande)
• Kod för att tolka LLM:ens verktygsanrop, anropa get_user_repos och injicera resultatet tillbaka i konversationen
• Felhantering för HTTP-fel, rate limits och utgången autentisering

MCP-server

from mcp.server.fastmcp import FastMCP
import httpx

mcp = FastMCP("github-server")

GITHUB_TOKEN = os.environ["GITHUB_TOKEN"]

@mcp.tool()
async def get_user_repos(username: str) -> str:
    """Hämta de 10 senast uppdaterade repositories för en GitHub-användare.

    Args:
        username: GitHub-användarnamn att slå upp
    """
    async with httpx.AsyncClient() as client:
        response = await client.get(
            f"https://api.github.com/users/{username}/repos",
            headers={
                "Authorization": f"Bearer {GITHUB_TOKEN}",
                "Accept": "application/vnd.github.v3+json",
                "X-GitHub-Api-Version": "2022-11-28"
            },
            params={"sort": "updated", "per_page": 10}
        )
        response.raise_for_status()
        repos = response.json()
        lines = []
        for r in repos:
            stars = r["stargazers_count"]
            lang = r["language"] or "okänt"
            lines.append(f"- {r['name']} ({lang}, {stars} stjärnor): {r['description'] or 'Ingen beskrivning'}")
        return "\n".join(lines)

if __name__ == "__main__":
    mcp.run(transport="stdio")

MCP-versionen kapslar in API-anropet, autentiseringen och svarsformateringen i servern. Alla MCP-kompatibla klienter kan använda det här verktyget utan att veta något om GitHub API.

Vad som ändras för AI-applikationen

Prestandajämförelse

MCP lägger till ett lager mellan AI-applikationen och det externa API:et. Det lagret har en kostnad.

Latens

För stdio-transport (lokala MCP-servrar) är overheaden minimal: processstart vid uppstart (engångskostnad, vanligtvis under 100ms) och interprocesskommunikation per meddelande (under en millisekund på moderna system). I praktiken dominerar det externa API-anropet den totala latensen.

För fjärrbaserade MCP-servrar (Streamable HTTP eller SSE) lägger du till en HTTP round-trip mellan klienten och MCP-servern, plus MCP-serverns HTTP round-trip till det externa API:et. Om MCP-servern och det externa API:et finns på samma plats är denna overhead liten (ensiffrigt antal millisekunder). Om de finns i olika regioner byggs den på. Transporten är dock sällan det användaren märker: när vi byggde en help-center-agent på Notions hostade MCP-server hade 248 verktygsanrop ett snitt på 2.7 sekunder vardera, nästan allt var Notion som sökte och renderade sidor snarare än hoppet däremellan.

För de flesta användningsfall med AI-agenter, där LLM-inferens tar 500ms-5s, är MCP-overheaden försumbar.

Anslutningshantering

Direkt HTTP: Din applikation hanterar anslutningar till varje externt API. Det innebär hantering av connection pools, retry-logik och rate limiting per API.

MCP: Din applikation hanterar en anslutning per MCP-server. Servern hanterar anslutningen till det externa API:et. Om du har 10 verktyg fördelade över 3 MCP-servrar hanterar du 3 anslutningar i stället för 10.

När du ska använda MCP

Flera verktygsintegrationer

Om din AI-applikation behöver ansluta till 5+ externa tjänster minskar MCP integrationsarbetet. I stället för att skriva och underhålla anpassade API-klienter för varje tjänst ansluter du till MCP-servrar (många av dem finns som open source-projekt).

Portabilitet mellan AI-plattformar

Om du bygger MCP-servrar för dina verktyg fungerar de servrarna med alla MCP-klienter: Claude Desktop, Cursor, Windsurf, anpassade applikationer och plattformar som Quickchat AI. Med direkt HTTP skulle du behöva implementera verktygsdefinitioner på nytt för varje plattforms format.

Dynamisk verktygsupptäckt

MCP stöder verktygsupptäckt vid körning genom tools/list. En AI-applikation kan ansluta till en server och lära sig vilka verktyg som finns tillgängliga utan någon hårdkodad konfiguration. Det är användbart i scenarier där verktyg ändras ofta eller kan konfigureras av användaren.

Ansvarsseparation

Om olika team äger olika verktyg ger MCP en tydlig gräns. Teamet som äger Salesforce-integrationen bygger och underhåller Salesforce MCP-servern. AI-applikationsteamet ansluter till den utan att behöva förstå Salesforces API. Uppdateringar av Salesforce API hanteras i MCP-servern utan att AI-applikationen behöver ändras.

När du ska använda direkt HTTP

En eller två integrationer

Om din AI-agent bara behöver anropa ett API (till exempel en databasuppslagning) är overheaden med att köra en MCP-server onödig. Ett direkt HTTP-anrop är enklare och har färre rörliga delar.

Du behöver inte heller skriva förfrågan för hand. API Action-byggaren på vanlig engelska läser ett dokumenterat REST API, genererar metoden, URL:en, parametrarna och beskrivningen, och låter dig sedan testa det riktiga svaret innan du aktiverar den.

Maximal kontroll över förfrågningar

MCP-servrar abstraherar bort HTTP-detaljerna. Om du behöver exakt kontroll över hur förfrågan konstrueras (specifika headers, query-parametrar, request signing eller icke-standardiserad autentisering) ger direkt HTTP dig den kontrollen utan att du behöver kämpa mot ett abstraktionslager.

Latenskänsliga operationer

Om varje millisekund spelar roll (till exempel röst-agenter i realtid där verktygsanrop måste slutföras inom strikta tidsbudgetar) eliminerar du ett hopp genom att ta bort MCP-lagret.

HTTP-anrop som inte är AI-relaterade

Om HTTP-anropet inte utlöses av en AI-agent (till exempel ett backend-cron-jobb som synkroniserar data) är MCP irrelevant. MCP är särskilt utformat för kommunikation mellan AI och verktyg. Vanliga backend-tjänster bör använda vanliga HTTP-klienter.

Hybridmetod

Många produktionssystem använder båda. Mönstret:

• MCP för verktygsintegrationer som AI-agenten anropar under konversationer (CRM-uppslagningar, skapande av tickets, frågor mot kunskapsbaser)
• Direkt HTTP för interna backend-operationer, webhooks och system-till-system-kommunikation

Det är så Quickchat AI fungerar internt. Plattformen stöder både HTTP Request Actions (direkta API-anrop med parametermallar) och Remote MCP Actions (anslutningar till externa MCP-servrar). Du väljer rätt metod för varje integration:

För en detaljerad jämförelse av hur detta fungerar i praktiken, inklusive skillnaderna mellan OpenAI:s GPT Actions och MCP, se GPT Actions vs MCP.

Beslutsramverk

Använd det här flödesschemat för att välja:

1. Anropar AI-agenten verktyget? Om nej (det är en backend-operation), använd direkt HTTP.
2. Hur många externa verktyg behöver du? Om 1-2 är direkt HTTP enklare. Om 3+, överväg MCP.
3. Finns det en färdig MCP-server för tjänsten? Om ja sparar du utvecklingstid genom att använda den.
4. Behöver integrationen fungera på flera AI-plattformar? Om ja ger MCP portabilitet.
5. Är latens kritiskt (under 100ms budget för verktygsanrop)? Om ja, mät MCP-overheaden och fatta beslut utifrån det.
6. Äger olika team olika integrationer? Om ja hjälper MCP:s modell med en server per integration till med ansvarsgränser.

I praktiken blir MCP i allt högre grad standardvalet om du bygger en AI-agent som behöver interagera med externa tjänster. Ekosystemet av färdiga servrar är tillräckligt stort för att du ofta ska kunna komma i gång utan att skriva någon serverkod alls.

Vidare läsning

• Anslut din AI Agent till en fjärrbaserad MCP-server: Ge din agent liveverktyg, steg för steg
• Så fungerar Model Context Protocol. MCP förklarat: Introduktion till MCP
• GPT Actions vs MCP: Jämförelse med OpenAI:s metod
• MCP-specifikation: Den officiella protokollspecifikationen
• HubSpot AI Actions: Exempel på HTTP-baserade AI-actions i praktiken
• OpenAI Hugging Face-incidenten, vad som faktiskt hände: Incidenten genomgången steg för steg, och vad hacking egentligen betyder