MCP vs API: Kdy použít MCP a kdy přímé HTTP

Když připojuješ AI agenta k externím nástrojům a API, existují dva hlavní přístupy: použít Model Context Protocol (MCP) jako abstrakční vrstvu, nebo volat API přímo přes HTTP. Oba přístupy fungují. Liší se kompromisy mezi flexibilitou, složitostí, výkonem a přenositelností.

Tento článek porovnává oba přístupy pomocí konkrétních příkladů kódu, analýzy latence a rámce pro rozhodování, který ti pomůže vybrat vhodnou variantu.

Dva přístupy

Přímá integrace přes HTTP

AI aplikace (nebo její backend) volá externí API přímo pomocí standardních HTTP požadavků. Vývojář píše kód pro sestavení požadavků, zpracování autentizace, parsování odpovědí a předání výsledků zpět LLM.

┌──────────┐     ┌────────┐                        ┌─────────────┐
│ Uživatel │────▶│ AI App │──── HTTP request ─────▶│ Weather API │
└──────────┘     │        │◀─── JSON response ─────│             │
                 │        │                        └─────────────┘
                 │        │── result as context ──▶ LLM
                 │        │◀── formatted answer ───
                 └───┬────┘
                     │
                     ▼
              Uživatel dostane odpověď

Integrace přes MCP

AI aplikace se připojí k MCP serveru, který obaluje externí API. Aplikace používá protokol MCP ke zjištění dostupných nástrojů, volá je podle názvu a přijímá výsledky. MCP server zajišťuje skutečná HTTP volání na externí API.

┌──────────┐     ┌───────────────────┐              ┌────────────┐     ┌──────────┐
│ Uživatel │────▶│ AI App/MCP Client │── JSON-RPC ─▶│ MCP Server │────▶│ HTTP API │
└──────────┘     │                   │◀─ JSON-RPC ──│            │◀────│          │
                 │                   │              └────────────┘     └──────────┘
                 │                   │── result as context ──▶ LLM
                 │                   │◀── formatted answer ───
                 └─────────┬─────────┘
                           │
                           ▼
                    Uživatel dostane odpověď

Hlavní rozdíl: u přímého HTTP vlastní kód pro integraci API AI aplikace. U MCP ho vlastní MCP server a AI aplikace pouze volá nástroje podle názvu.

MCP část tohoto diagramu můžeš mít bez vytváření serveru: Quickchat AI hostuje streamable-HTTP MCP server pro každého AI Agenta a proměna tvého agenta v MCP server znamená jen vložit jednu URL do AI aplikace.

Porovnání kódu

Porovnejme oba přístupy na praktickém příkladu: načtení repozitářů uživatele na GitHubu.

Přímá integrace přes HTTP

import httpx

async def get_user_repos(username: str, token: str) -> list[dict]:
    """Načte repozitáře uživatele na GitHubu."""
    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
        ]

Aby ses tím integroval s LLM, potřebuješ také:

• Definici nástroje ve formátu, který LLM očekává (schéma OpenAI function calling, schéma Claude tool use a podobně)
• Kód pro parsování volání nástroje z LLM, vyvolání get_user_repos a vložení výsledku zpět do konverzace
• Ošetření chyb pro selhání HTTP, rate limity a vypršení autentizace

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:
    """Načte 10 naposledy aktualizovaných repozitářů uživatele na GitHubu.

    Args:
        username: uživatelské jméno na GitHubu, které se má vyhledat
    """
    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 "unknown"
            lines.append(f"- {r['name']} ({lang}, {stars} hvězdiček): {r['description'] or 'Bez popisu'}")
        return "\n".join(lines)

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

Verze s MCP zapouzdřuje volání API, autentizaci a formátování odpovědi uvnitř serveru. Libovolný klient kompatibilní s MCP může tento nástroj použít, aniž by cokoli věděl o GitHub API.

Co se mění pro AI aplikaci

Porovnání výkonu

MCP přidává vrstvu mezi AI aplikaci a externí API. Tato vrstva má náklady.

Latence

U stdio transportu (lokální MCP servery) je režie minimální: spuštění procesu při startu (jednorázově, typicky pod 100ms) a meziprocesová komunikace pro každou zprávu (pod milisekundu na moderních systémech). V praxi v celkové latenci dominuje volání externího API.

U vzdálených MCP serverů (Streamable HTTP nebo SSE) přidáváš jeden HTTP round-trip mezi klientem a MCP serverem a k tomu HTTP round-trip z MCP serveru na externí API. Pokud jsou MCP server a externí API ve stejné lokalitě, režie je malá (jednotky milisekund). Pokud jsou v různých regionech, sčítá se. Transport ale uživatel obvykle nevnímá: při vytváření agenta help centra na hostovaném MCP serveru Notion mělo 248 volání nástrojů průměr 2.7 sekundy na volání a téměř celý čas připadal na vyhledávání v Notion a renderování stránek, ne na mezikrok mezi nimi.

U většiny případů použití AI agentů, kde inference LLM trvá 500ms-5s, je režie MCP zanedbatelná.

Správa připojení

Přímé HTTP: Tvoje aplikace spravuje připojení ke každému externímu API. To znamená zpracování connection poolů, logiky opakování a rate limitingu pro každé API.

MCP: Tvoje aplikace spravuje jedno připojení na MCP server. Server spravuje připojení k externímu API. Pokud máš 10 nástrojů rozložených mezi 3 MCP servery, spravuješ 3 připojení místo 10.

Kdy použít MCP

Více integrací nástrojů

Pokud se tvoje AI aplikace potřebuje připojit k 5+ externím službám, MCP snižuje integrační zátěž. Místo psaní a údržby vlastních API klientů pro každou službu se připojíš k MCP serverům (mnohé jsou dostupné jako open-source projekty).

Přenositelnost mezi AI platformami

Pokud pro své nástroje vytvoříš MCP servery, tyto servery fungují s libovolným MCP klientem: Claude Desktop, Cursor, Windsurf, vlastní aplikace a platformy jako Quickchat AI. U přímého HTTP bys musel znovu implementovat definice nástrojů pro formát každé platformy.

Dynamické zjišťování nástrojů

MCP podporuje zjišťování nástrojů za běhu pomocí tools/list. AI aplikace se může připojit k serveru a zjistit, jaké nástroje jsou dostupné, bez pevně zadané konfigurace. To je užitečné ve scénářích, kde se nástroje často mění nebo jsou konfigurovatelné uživatelem.

Oddělení odpovědností

Pokud různé týmy vlastní různé nástroje, MCP poskytuje čistou hranici. Tým, který vlastní integraci Salesforce, vytvoří a udržuje Salesforce MCP server. Tým AI aplikace se k němu připojí bez nutnosti rozumět Salesforce API. Aktualizace Salesforce API se řeší v MCP serveru bez zásahů do AI aplikace.

Kdy použít přímé HTTP

Jedna nebo dvě integrace

Pokud tvůj AI agent potřebuje volat jen jedno API (například databázové vyhledání), režie spojená s provozem MCP serveru není nutná. Přímé HTTP volání je jednodušší a má méně pohyblivých částí.

Požadavek také nemusíš psát ručně. Tvůrce API Action v běžné angličtině přečte zdokumentované REST API, vygeneruje metodu, URL, parametry a popis a pak ti umožní otestovat skutečnou odpověď před zapnutím.

Maximální kontrola nad požadavky

MCP servery abstrahují HTTP detaily. Pokud potřebuješ přesnou kontrolu nad sestavením požadavku (specifické hlavičky, query parametry, podepisování požadavků nebo nestandardní autentizaci), přímé HTTP ti tuto kontrolu poskytne bez boje s abstrakční vrstvou.

Operace citlivé na latenci

Pokud záleží na každé milisekundě (například real-time hlasoví agenti, u kterých se volání nástrojů musí dokončit v přísných časových limitech), odstranění vrstvy MCP eliminuje jeden mezikrok.

HTTP volání mimo AI

Pokud HTTP volání nespouští AI agent (například backendový cron job, který synchronizuje data), MCP není relevantní. MCP je navrženo konkrétně pro komunikaci mezi AI a nástroji. Běžné backendové služby by měly používat běžné HTTP klienty.

Hybridní přístup

Mnoho produkčních systémů používá obojí. Vzor:

• MCP pro integrace nástrojů, které AI agent volá během konverzací (vyhledávání v CRM, vytváření ticketů, dotazy do znalostní báze)
• Přímé HTTP pro interní backendové operace, webhooky a komunikaci mezi systémy

Takto interně funguje Quickchat AI. Platforma podporuje HTTP Request Actions (přímá API volání se šablonováním parametrů) i Remote MCP Actions (připojení k externím MCP serverům). Pro každou integraci si vybereš správný přístup:

Podrobné porovnání toho, jak to funguje v praxi, včetně rozdílů mezi GPT Actions od OpenAI a MCP, najdeš v článku GPT Actions vs MCP.

Rámec pro rozhodování

Použij tento diagram rozhodování:

1. Volá nástroj AI agent? Pokud ne (jde o backendovou operaci), použij přímé HTTP.
2. Kolik externích nástrojů potřebuješ? Pokud 1-2, přímé HTTP je jednodušší. Pokud 3+, zvaž MCP.
3. Existuje pro danou službu hotový MCP server? Pokud ano, jeho použití ušetří čas vývoje.
4. Potřebuješ, aby integrace fungovala napříč více AI platformami? Pokud ano, MCP poskytuje přenositelnost.
5. Je latence kritická (rozpočet pod 100ms pro volání nástrojů)? Pokud ano, změř režii MCP a podle toho se rozhodni.
6. Vlastní různé integrace různé týmy? Pokud ano, model MCP s jedním serverem na integraci pomáhá s hranicemi odpovědnosti.

V praxi platí, že pokud vytváříš AI agenta, který potřebuje pracovat s externími službami, MCP se stále častěji stává výchozí volbou. Ekosystém hotových serverů je dostatečně rozsáhlý na to, aby ses často mohl začít používat bez psaní jakéhokoli serverového kódu.

Další čtení

• Připoj svého AI Agenta ke vzdálenému MCP Serveru: Dej svému agentovi živé nástroje, krok za krokem
• Jak funguje Model Context Protocol. Vysvětlení MCP: Úvod do MCP
• GPT Actions vs MCP: Porovnání s přístupem OpenAI
• Specifikace MCP: Oficiální specifikace protokolu
• HubSpot AI Actions: Příklad AI actions založených na HTTP v praxi
• Incident OpenAI Hugging Face, co se skutečně stalo: Incident vysvětlený krok za krokem a co hacking skutečně znamená