MCP zur Agen­ten-Ermäch­ti­gung mit­tels Daten­ban­ken und Tools



Model Con­text Pro­to­col: Wie MCP für KI-Agen­ten funktioniert

Das Model Context Proto­col (kurz MCP) beschreibt einen offe­nen Pro­to­koll­stan­dard zur Ver­bin­dung von KI-Agen­ten (oft basie­rend auf Large Lan­guage Models, LLMs) mit exter­nen Daten­quel­len, Tools und Sys­te­men. Umge­setzt wird dies mit einer ein­heit­li­chen Kon­fi­gu­ra­tion der Schnitt­stelle für alle Kom­po­nen­ten, wes­we­gen MCP auch oft als “USB‑C für KI” bezeich­net wird. Hier­bei ist das große Ziel die Reduk­tion von vie­len indi­vi­du­el­len Inte­gra­tio­nen auf eine Inte­gra­tion pro ange­bun­de­ner Komponente.

KI-Agen­ten sind in die­sem Kon­text LLMs, die eigen­stän­dig User-Anwei­sun­gen umset­zen. Tools bezeich­net zusätz­li­che Soft­ware, die von die­sen Agen­ten mit­tels gene­rier­ter Syn­tax bedient wer­den kann. Hier­bei pas­siert die Ver­knüp­fung über MCP.

Gezeigt sind ver­schie­dene KI-Anwen­dun­gen, Daten­quel­len und Tools, wel­che bereits über eine MCP Schnitt­stelle erreich­bar sind Quelle.

Ent­wi­ckelt wurde MCP von Anthro­pic (Bekannt durch die Claude LLM-Modelle), wel­che die Rechte an MCP zur Wah­rung der Unab­hän­gig­keit mitt­ler­weile an die Linux-Foun­da­tion abge­ge­ben haben, wo MCP eine Apache‑2.0‑Lizenz trägt.

Warum ist MCP so hilfreich?

KI-Agen­ten, wel­che auf Large Lan­guage Models (LLM) basie­ren, wer­den in immer mehr Berei­chen ange­wandt, um eigen­stän­dig User-Anfra­gen zu bearbeiten.

Bis­her war oft das Pro­blem, dass KI-Agen­ten hier eine andere „Spra­che“ als geläu­fige Soft­ware-Tools spre­chen, wes­we­gen der User die Kom­mu­ni­ka­tion über­neh­men musste.

MCP löst als neuer Stan­dard die­ses Pro­blem, indem die Kom­mu­ni­ka­tion ver­ein­heit­licht wird. Dar­aus resul­tie­rend kann ein ein­mal ange­schlos­se­ner KI-Agent direkt mit diver­sen Tools kom­mu­ni­zie­ren und interagieren.

Kom­po­nen­ten von MCP

Grund­le­gend ist MCP in einer Cli­ent-Ser­ver Archi­tek­tur auf­ge­baut, mit fol­gen­den Bestandteilen:

  • MCP-Host:
    • KI Anwen­dung, wel­che eine belie­bige Anzahl MCP-Cli­ents ver­wen­det, koor­di­niert und verwaltet
  • MCP-Cli­ent:
    • Ver­wal­tet die Ver­bin­dung zum MCP-Ser­ver. Erhält Infor­ma­tio­nen und Kon­text, um diese an den MCP-Host zur Ver­wen­dung weiterzugeben.
  • MCP-Ser­ver:
    • Stellt Infor­ma­tio­nen und Kon­text für den MCP-Cli­ent bereit

Die Kom­mu­ni­ka­tion zwi­schen den Kom­po­nen­ten erfolgt über den JSON RPC 2.0 Standard.

Der Auf­bau der MCP Struk­tur beinhal­tet den MCP-Cli­ent, den MCP-Ser­ver und die ange­bun­de­nen Kom­po­nen­ten, die Kom­mu­ni­ka­tion erfolgt über Json RPC 2.0.

Vor­teile der MCP Technologie

MCP bie­tet für die Anbin­dung von KI-Agen­ten man­nig­fal­tige Vorteile.

Als Ers­tes ist ein MCP-Ser­ver ein res­sour­cen­güns­ti­ger Ansatz, um KI in Pro­zesse zu inte­grie­ren. Dabei fun­giert der Host als Media­tor zwi­schen ver­schie­de­nen Datenbanken/Tools/Websites. Dadurch kön­nen diverse Tools und Funk­tio­na­li­tä­ten von Agen­ten oder User ange­steu­ert werden.

Zwei­tens wird der KI-Agent über MCP ansteu­er­bar und selbst­stän­dig. Bei­spiels­weise kön­nen direkt Daten­ban­ken oder Git ange­bun­den wer­den, die der KI-Agent eigen­stän­dig durch­su­chen kann. Außer­dem kön­nen Tools aus dem Geschäfts­all­tag ver­knüpft wer­den, so dass bei­spiels­weise Slack-Nach­rich­ten beant­wor­tet oder Google Drive Dateien ver­wal­tet wer­den können.

Zuletzt sind MCP Schnitt­stel­len auch wie­der ver­wend­bar, d.h. sie kön­nen aus ver­schie­de­nen Quel­len ange­steu­ert wer­den. Dadurch kön­nen Archi­tek­tu­ren von einer schnell explo­die­ren­den Anzahl an Inte­gra­tio­nen (N(KI-Clients) x M(Server)) zu einer über­sicht­li­chen Anzahl (N+M) redu­ziert wer­den. Außer­dem hat es zur Folge, dass auch der genutzte KI-Agent ohne viel Auf­he­ben aus­ge­tauscht wer­den kann.

Vor MCP musste für jede Ver­bin­dung eines Tools mit einem KI-Agen­ten eine eigene Schnitt­stelle bereit­ge­stellt wer­den. Durch MCP kann die Kom­mu­ni­ka­tion über eine uni­ver­selle, wie­der­ver­wend­bare Schnitt­stelle laufen.

Unsi­cher­hei­ten der MCP-Technologie

Aus der gro­ßen Ein­fach­heit in der Kom­mu­ni­ka­tion mit­tels MCP erwach­sen natür­lich auch Sicherheitsrisiken.

Zum einen sind viele Ser­ver offen erreich­bar, wodurch es zu Män­geln in der Sicher­heit der gesen­de­ten und emp­fan­ge­nen Daten kom­men kann.

Zum Ande­ren bie­tet die Bereit­stel­lung einer Schnitt­stelle zu den eige­nen KI-Agen­ten eine Angriffs­stelle für Prompt Injec­tions (ins­be­son­dere bei einem so genann­ten „töd­li­chem Triple“):

  1. Agent ver­ar­bei­tet kom­pro­mit­tierte Inputs 
    • z.B. Mails, Git­hub pull requests
  2. Agent mit Zugang zu inter­nen Daten 
    • Kann bei­spiels­weise Daten­ban­ken querien
  3. Agent kann Infor­ma­tio­nen aus inter­nem Sys­tem versenden 
    • Bei­spiels­weise per Mail

Wenn alle drei Punkte erfüllt wer­den, kann der KI-Agent mit bös­ar­ti­gen Anfra­gen kom­pro­mit­tiert wer­den und dadurch z.B. interne Unter­neh­mens­da­ten an Dritte ver­sen­den. Der erste Sicher­heits­me­cha­nis­mus zur Prä­ven­tion wäre eine Frei­gabe durch die zustän­dige Per­son (human-in-the-loop, s.u.). Aller­dings kön­nen die bös­ar­ti­gen Prompts bei geschick­ter Kon­fi­gu­ra­tion (Ver­ste­cken am Ende eines lan­gen Prompts, wei­ßer Text auf wei­ßem Grund) auch an einem auf­merk­sa­men Beob­ach­ter vor­bei­ge­schleust wer­den. Auf die Frage, wie viele Rechte ein KI-Agent für eine bestimmte Auf­gabe wirk­lich braucht, sollte also immer beson­de­res Augen­merk gelegt werden. 

Dar­über hin­aus kön­nen kom­pli­zierte Fra­ge­stel­lun­gen fal­sche, womög­lich hal­lu­zi­nierte, Ergeb­nisse lie­fern, da oft ein pro­ba­bi­lis­ti­sches Modell für deter­mi­nis­ti­sche Auf­ga­ben ein­ge­setzt wird. Für Pro­blem­stel­lun­gen, in denen KI-Agen­ten auf SQL-fähi­gen Daten­ban­ken deter­mi­nis­ti­sche Ant­wor­ten lie­fern sol­len, bie­ten Multi-Agen­ten Sys­teme in Text-to-SQL einen Ausweg.

In der Kom­mu­ni­ka­tion zwi­schen User und KI-Agent kann es zu bös­ar­ti­gen Resul­ta­ten kom­men, wenn bei­spiels­weise ange­bun­dene MCP Ser­ver oder Tools kom­pro­mit­tiert sind. Quelle

Mög­li­che Sicherheitsmaßnahmen

Zur Absi­che­rung von MCP Archi­tek­tu­ren gibt es ver­schie­dene Möglichkeiten.

Für Authen­ti­fi­zie­rung von remote HTTP Ser­vern steht das OAuth 2.1 Frame­work zur Verfügung. 

Außer­dem gibt es ver­schie­dene Best Prac­ti­ces um Sicher­heits­lü­cken im Vor­hin­ein zu vermeiden:

  • Vor­he­rige Über­prü­fung (Input Vali­da­tion):
    • Bevor ein Pro­gramm Befehle des Agen­ten aus­führt, müs­sen Input Para­me­ter rigo­ros vali­diert werden.
  • So wenig Rechte wie mög­lich (Least Pri­vi­lege):
    • Jedes Tool erhält nur kleinst­mög­li­che Berech­ti­gung (sen­si­ble Datenbanken).
  • Finale Über­prü­fung (Human-in-the-Loop):
    • Für wich­tige Aktio­nen (z.B. Über­wei­sun­gen) berei­tet Agent nur alles vor, finale Bestä­ti­gung erfor­dert immer Menschen.
  • Ver­schlüs­se­lung (Data Mas­king):
    • Beson­ders sen­si­ble Daten (Pass­wör­ter, Sozi­al­ver­si­che­rungs­num­mern) wer­den unkennt­lich gemacht oder ver­schlüs­selt, bevor Agent Zugang bekommt.

MCPs gol­dene Zukunft?

Mitt­ler­weile setzt sich MCP immer mehr als der Stan­dard durch und ist mit allen gro­ßen kom­mer­zi­el­len LLMs (ChatGPT, Claude, Gemini etc.) kom­pa­ti­bel. Die Vor­teile für den Arbeits­all­tag über­wie­gen klar mög­li­che Risi­ken durch die Neu­heit der Technologie:

  • Der User wird zum Mana­ger im Arbeitsalltag
    • Aus­ge­wählte Agen­ten mit bereit­ge­stell­ten Tools erle­di­gen die Fleiß­ar­beit im Arbeitsalltag.
    • Hier­ar­chi­sche Sys­teme von Agen­ten kön­nen auch kom­plexe Workloads bewältigen.
  • Schnell wach­sen­des Öko-Sys­teme lie­fern viel­fäl­tige Lösungen
    • Anthro­pic bie­tet schon vor­ge­fer­tigte Ser­ver an.
    • Viele große Unter­neh­men fol­gen direkt (Git, Slack, Google Drive, …).
    • Dar­über­hin­aus ersetzt MCP nicht nur bis­he­rige Schnitt­stel­len, son­dern bie­tet teil­weise auch neue Inter­faces für ander­wei­tig schwie­rige anzu­spre­chende Pro­gramme an, die direkt über MCP anzu­spre­chen sind.
  • Für neue Sicher­heits­kon­zepte bie­tet MCP auch Abhilfe, indem z.B. Proxy-Sys­teme zwi­schen Ser­ver geschal­tet wer­den können,
  • MCP ermög­licht die Aus­tausch­bar­keit der KI-Agenten:
    • Ver­schie­denste Fir­men haben ihre KI-Agen­ten an MCP angeschlossen.
    • Dadurch ist ein ein­fa­ches Aus­wech­seln je nach Usecase mög­lich, ohne die Code­base ändern zu müssen.
  • Inse­ge­samt bie­tet MCP ein gewal­ti­ges Poten­tial in KI-Workflows:
    • Denn es eröff­net einen ein­fa­chen und vor­ge­fer­tig­ten Weg diverse Auf­ga­ben an KI auszulagern.
MCP ermög­licht es KI-Agen­ten, über Tools diverse Auf­ga­ben zu über­neh­men und somit den User wirk­sam zu ent­las­ten. Quelle

Der Ein­fluss von MCP wird stark von der jewei­li­gen Bran­che abhän­gen. Aus der Ver­net­zung von Tools und Agen­ten wer­den sich viele neue StartUp-Ideen erge­ben. Für den Nor­mal­ver­brau­cher wird MCP aber eine Tech­no­lo­gie im Hin­ter­grund blei­ben, die auch ohne tech­ni­sches Ver­ständ­nis den All­tag erleich­tert, wie bei­spiels­weise Bluetooth.

Mög­li­che Einsatzfelder

MCP kann für diverse Lösun­gen ein­ge­setzt wer­den, dar­un­ter z.B.:

  • Auto­ma­ti­sche Markt­for­schung: Der Agent sucht täg­lich selbst­stän­dig im Inter­net nach The­men und lie­fert Zusammenfassungen.
  • Eigen­stän­di­ger Coding-Assis­tent: Git com­mits wer­den auto­ma­tisch vor­be­rei­tet oder kom­plexe Soft­ware-Bau­steine via online-Doku­men­ta­tion erklärt/in Infra­stru­cure as code übersetzt.
  • Mes­sen­ger als Schalt­zen­trale: Auf­träge via KI-Agen­ten an Tools ver­ge­ben, direkt aus dem Mes­sen­ger (z.B. Slack).
  • Intel­li­gen­tes Zeit­ma­nage­ment: Direkte Kalen­der­pflege aus Mails und Nachrichten.
  • Naht­lose Daten­ver­knüp­fung: Zeit­glei­cher Zugriff auf interne und externe Doku­mente erlaubt Agen­ten begrün­dete Ant­wor­ten mit Kon­text zu lie­fern (Stich­wort RAG).
  • Agent im lau­fen­dem Betrieb: Agent, der CI/CD pipe­line beauf­sich­tigt. Bei Feh­lern kann die­ser direkt Logs durch­su­chen und Men­schen mit Ver­weis auf feh­ler­haf­ten Code und vor­ge­schla­ge­nen Fix benachrichtigen.

Buil­ding your own MCP-Server

Die Anbin­dung ver­schie­de­ner Tools kann direkt über Python erfol­gen. Im nach­fol­gen­den Bei­spiel wird ein loka­ler MCP Ser­ver gebaut, der direkt auf der Maschine des Users läuft. Die MCP Schnitt­stelle von Slack ermög­licht die Kom­mu­ni­ka­tion direkt im Mes­sen­ger. Ein auf Llama basie­ren­der KI-Agent benutzt je nach Anfrage ver­schie­dene Tools. Tavily ermög­licht dem KI-Agen­ten, für Fra­gen das Web zu durch­su­chen, wohin­ge­gen die Snow­flake-MCP-Schnitt­stelle zum Abfra­gen einer Daten­bank befähigt.

Die vor­ge­stellte Archi­tek­tur besteht aus einem lokal lau­fen­den Python-Pro­gramm, wel­ches Llama als KI-Agen­ten, Snow­flake als Daten­bank, Tavily für Web-Suchen und Slack als Inter­face für den User nutzt.

Snow­flake stellt direkt eine MCP Schnitt­stelle auf die zugrun­de­lie­gende Daten­bank bereit, auf die zuge­grif­fen wer­den kann, wenn die Anfrage über die not­wen­di­gen Cre­den­ti­als ver­fügt. Die MCP Schnitt­stelle wird über FastMCP aus der Python-Library mcp.server.fastmcp angebunden.

mcp = FastMCP(«snowflake_query_server»)

load_dotenv()

# 2️⃣ Con­nect to Snowflake

def init_snowflake():

    user = os.getenv(«SNOWFLAKE_USER»)

    pass­word = os.getenv(«SNOWFLAKE_PASSWORD»)

    account = os.getenv(«SNOWFLAKE_ACCOUNT»)

    ware­house = os.getenv(«SNOWFLAKE_WAREHOUSE»)

    data­base = os.getenv(«SNOWFLAKE_DATABASE»)

    schema = os.getenv(«SNOWFLAKE_SCHEMA»)

    role = os.getenv(«SNOWFLAKE_ROLE»)

    conn = snowflake.connector.connect(

        user=user,

        password=password,

        account=account,

        warehouse=warehouse,

        database=database,

        schema=schema,

        role=role,

    )

    print(«✅ Con­nec­ted to Snow­flake», «with file», sys.stderr, file=sys.stderr)

    return conn

snowflake_conn = init_snowflake()

Genauso hat der Mes­sen­ger Slack eine MCP Schnitt­stelle, über die Unter­hal­tun­gen abge­fragt oder ein Bot ange­steu­ert wer­den kann. Dadurch kann der Slack Mes­sen­ger als Inter­face für die Inter­ak­tion mit dem KI-Agen­ten genutzt werden.

APP_TOKEN = os.environ.get(«SLACK_APP_TOKEN»)

BOT_TOKEN = os.environ.get(«SLACK_BOT_TOKEN»)

app = App(token=BOT_TOKEN)

slack_post_queue = queue.Queue()

# — Slack Post Worker —

def slack_post_worker():

    while True:

        item = slack_post_queue.get()

        if item is None:

            break

        msg_id, chan­nel, text = item

        try:

            app.client.chat_postMessage(channel=channel, text=text)

            print(f»[INFO] Slack API Suc­cess: {chan­nel}», file=sys.stderr, flush=True)

        except Excep­tion as e:

            print(f»[ERROR] Slack API Fail­ure: {e}», file=sys.stderr, flush=True)

Der lokale Ser­ver in die­sem Bei­spiel star­tet die Sub­pro­zesse, damit diese via MCP ansprech­bar sind.

# —————————

# Ser­ver Startup Function

# —————————

def start_mcp(cmd, name):

    proc = subprocess.Popen(

        cmd,

        stdin=subprocess.PIPE,

        stdout=subprocess.PIPE,

        stderr=subprocess.PIPE,

        text=True,

        bufsize=1,

    )

    q = queue.Queue()

    threading.Thread(

        target=read_output, args=(proc.stdout, q, name), daemon=True

    ).start()

    return proc, q

# — Ser­ver Start —

chat_proc, chat_q = start_mcp([sys.executable, «chatgpt_mcp_server.py»], «ChatGPT»)

snow_proc, snow_q = start_mcp([sys.executable, «snowflake_mcp_server.py»], «Snow­flake»)

duck_proc, duck_q = start_mcp([sys.executable, «tavily_mcp_server.py»], «Tavily»)

slack_proc, slack_q = start_mcp([sys.executable, «slack_mcp_server.py»], «Slack»)

# — Ser­ver Start —

chat_proc, chat_q = start_mcp([sys.executable, «chatgpt_mcp_server.py»], «ChatGPT»)

snow_proc, snow_q = start_mcp([sys.executable, «snowflake_mcp_server.py»], «Snow­flake»)

duck_proc, duck_q = start_mcp([sys.executable, «tavily_mcp_server.py»], «Tavily»)

slack_proc, slack_q = start_mcp([sys.executable, «slack_mcp_server.py»], «Slack»)

# — MCP Hand­shakes (Cru­cial for start­ing servers) —

def initialize_mcp(proc, q, name):

    if name == «ChatGPT»:

        payload = {

            «jsonrpc»: «2.0»,

            «id»: 0,

            «method»: «session/initialize»,

            «params»: {},

        }

    else:

        payload = {

            «jsonrpc»: «2.0»,

            «id»: 0,

            «method»: «initia­lize»,

            «params»: {

                «pro­to­col­Ver­sion»: «2024–11-05»,

                «cli­ent­Info»: {«name»: name, «ver­sion»: «1.0»},

                «capa­bi­li­ties»: {},

            },

        }

    send(proc, payload)

    recv(q, timeout=10)

    if name == «Snow­flake»:

        send(

            proc,

            {«jsonrpc»: «2.0», «method»: «notifications/initialized», «params»: {}},

        )

initialize_mcp(chat_proc, chat_q, «ChatGPT»)

initialize_mcp(snow_proc, snow_q, «Snow­flake»)

initialize_mcp(slack_proc, slack_q, «Slack»)

Um dem KI-Agen­ten zu erlau­ben, ver­schie­dene Tools fun­diert aus­zu­wäh­len, kön­nen die zugrun­de­lie­gen­den Prompts mit zusätz­li­chen Infor­ma­tio­nen ver­se­hen oder über Schlüs­sel­wör­ter ange­steu­ert wer­den. Im unten gezeig­ten Code-Snip­pet ist der Prompt gezeigt, um den der KI-Agent anzu­lei­ten, ob eine Web­su­che oder eine SQL-Query geeig­net sind, um die Anfrage zu beant­wor­ten. Außer­dem ist der Kon­text der Daten­bank auf­ge­führt, damit der KI-Agent kor­rekte SQL-Syn­tax erzeugt.

def ask_and_execute(prompt, slack_channel=None):

    «»«The ‹Brain›: Deci­des bet­ween SQL or SEARCH and executes.»»»

    glo­bal msg_id_chat, msg_id_snow

    agent_instructions = «»»

    You are a Stra­te­gic Data Agent with access to two tools:

    TOOL 1: SNOWFLAKE (Inter­nal Data)

    – Use for: Sales, cus­to­mer info, pro­duct details, per­for­mance metrics.

    – Schema Context:

        * View ‹V_SALES_PERFORMANCE›: [SALE_DATE, CUSTOMER_NAME, COUNTRY, PRODUCT_NAME, CATEGORY, TOTAL_AMOUNT, SEGMENT]

        * Table ‹CUSTOMERS›: [CUSTOMER_ID, NAME, SEGMENT, COUNTRY, JOIN_DATE]

        * Table ‹PRODUCTS›: [PRODUCT_ID, PRODUCT_NAME, CATEGORY, PRICE]

        * Table ‹SALES›: [SALE_ID, SALE_DATE, CUSTOMER_ID, PRODUCT_ID, QUANTITY, TOTAL_AMOUNT]

    – Rules: Use UPPERCASE for iden­ti­fiers. Return ONLY raw SQL start­ing with ‹SQL: ‹.

    TOOL 2: WEB_SEARCH (Exter­nal Data)

    – Use for: News, stocks, world facts, gene­ral knowledge.

    – Rules: Return ‹SEARCH: <opti­mi­zed search query>›.

    DECISION RULE:

    – If inter­nal data is nee­ded, respond with ‹SQL: <sql query>›.

    – If external/current info is nee­ded, respond with ‹SEARCH: <query>›.

    «»»

    full_prompt = f»{agent_instructions}\n\nUser Ques­tion: {prompt}»

    with chat_lock:

        send(

            chat_proc,

            {

                «jsonrpc»: «2.0»,

                «id»: 999,

                «method»: «tools/call»,

                «params»: {«name»: «ask_chatgpt», «argu­ments»: {«prompt»: full_prompt}},

            },

        )

        response = recv(chat_q, timeout=60)

tools:

def handle_search(request):

    params = request.get(«params», {})

    args = params.get(«arguments», {})

    query = args.get(«query»)

    if not query:

        return {

            «jsonrpc»: «2.0»,

            «id»: request.get(«id»),

            «error»: {«code»: ‑32602, «mes­sage»: «Miss­ing query»},

        }

    try:

        # Reques­t­ing search results AND a syn­the­si­zed answer

        response = requests.post(

            «https://api.tavily.com/search»,

            json={

                «api_key»: TAVILY_API_KEY,

                «query»: query,

                «search_depth»: «basic»,

                «max_results»: 3,

                «include_answer»: True,  # Get the direct ans­wer from Tavily

            },

            timeout=15,

        )

Die Nach­rich­ten wer­den im Hin­ter­grund mit­tels JSON RPC 2.0 über­tra­gen. Der User kann im CLI ver­fol­gen, wel­che Daten im Hin­ter­grund wohin gesen­det wer­den. Die kom­plette Kom­mu­ni­ka­tion kann aber auf­be­rei­tet in Slack erfolgen.

Ein Bei­spiel für den Out­put des loka­len MCP Ser­vers. Alle Kom­mu­ni­ka­tion in beide Rich­tun­gen wird in JSON ver­packt. Snow­flake bei­spiels­weise wird über eine vom KI-Agen­ten gene­rierte SQL-Query angesprochen.

Über die Slack Anbin­dung kön­nen User direkt im gewohn­ten Mes­sen­ger mit ihrem KI-Agen­ten kom­mu­ni­zie­ren und Fra­gen stel­len. Der KI-Agent ent­schei­det eigen­stän­dig, ob für diese Beant­wor­tung eine Web­su­che oder eine SQL-Query auf der Snow­flake Instanz bes­ser ist, um die Frage opti­mal zu beantworten.

Der User hat im All­tag eine Frage, die der KI-Agent direkt mit eige­ner Web­su­che beantwortet.

Außer­dem kann über die ange­bun­dene Snow­flake-Instanz direkt die zugrun­de­lie­gende Daten­bank durch­sucht wer­den, wenn der User schnell kon­krete Zah­len zu einem bestimm­ten Kun­den braucht.

Der User hat eine Frage zu kon­kre­ten Fir­men­da­ten. Der KI-Agent hal­lu­zi­niert keine Fak­ten, son­dern gene­riert eine SQL-Query, wel­che die­ses Resul­tat daten­ba­siert bereit­stellt. Auch bei Tipp­feh­lern im Prompt erkennt der KI-Agent die eigent­li­che Frage und ant­wor­tet korrekt.

Fazit

Zusam­men­fas­send lässt sich sagen, dass MCP viele Pro­bleme ver­gan­ge­ner KI-Lösun­gen behebt. MCP been­det die Ära, in der KI-Agen­ten „iso­liert“ arbei­te­ten. Es stan­dar­di­siert Kom­mu­ni­ka­tion im digi­ta­len Mit­ein­an­der. Ein gemein­sa­mes Pro­to­koll erlaubt bes­sere Kon­trolle dar­über, wel­che Daten flie­ßen und wel­che nicht. Auch bis­he­rige tech­ni­sche Hür­den wer­den nach und nach aus­ge­räumt, wäh­rend MCP immer mehr zum Stan­dard in der KI-Kom­mu­ni­ka­tion wird. Der Zugriff auf Daten und Tools erlaubt KI-Agen­ten vom blo­ßen Gesprächs­part­ner zu mäch­ti­gen, eigen­stän­di­gen Hel­fern zu wer­den, um User viel­sei­tig zu unter­stüt­zen. Denn es sind bereits diverse MCP-Ser­ver vor­han­den, die Tools für fast jeden use case anbieten.

Am bes­ten stei­gen alle jetzt schon ein und pro­bie­ren diese neue Lösung aus!