mcprepo.ai

Veroffentlicht am

- 12 min read

Best Practices zur Skalierung kontextbezogener Daten mit MCP-Repositories

#Modellkontext #MCP-Repositories #Kontextskalierung #Wissensdesign #KI-Infrastruktur]
Bild von Best Practices zur Skalierung kontextbezogener Daten mit MCP-Repositories

Best Practices zum Skalieren kontextueller Daten mit MCP-Repositories

Kontext ist Ihre neue Produktionsdatenbank. Behandeln Sie ihn leichtfertig, und er wird stillschweigend alles begrenzen, was Sie darauf aufbauen.

Dies ist ein Leitfaden, um das zu verhindern.

1. Beginnen Sie mit einer Kontextstrategie, nicht mit einer Wunschliste für Tools

MCP-Repositories wirken verlockend wie eine weitere Integrationsschicht: anschließen, auf Ihre Daten zeigen, dem Modell die Arbeit überlassen. Diese Denkweise ist genau das, was die meisten kontextuellen Systeme bei einem „coolen Demo“ statt bei dauerhafter Leistungsfähigkeit ausbremst.

Bevor Sie sich Sorgen um Adapter, Embeddings oder Retrieval-Tricks machen, beantworten Sie vier harte Fragen:

  1. Wer ist der primäre Konsument dieses Kontexts?

    • Ein Support-Copilot? Ein interner Analysten-Assistent? Ein Helfer fürs Programmieren?
    • Jede Persona braucht unterschiedliche Granularität, Latenz und Sicherheitsgarantien.

  2. Welche Entscheidungen oder Workflows erwarten Sie, dass sich ändern?

    • „Mehr Tickets automatisch beantworten“ ist kein Workflow.
    • „Abrechnungs- vs. technische Tickets klassifizieren, Antwort entwerfen, Rückerstattungsklasse vorschlagen“ ist einer.

  3. Welcher Fehlermodus ist akzeptabel?

    • Ist „Ich weiß es nicht“ akzeptabel?
    • Oder muss der Assistent immer antworten, selbst wenn das bedeutet, veraltete oder unvollständige Daten zu verwenden?

  4. Welche Quellen sind autorität gegenüber nur hilfreich?

    • Autoritativ: Verträge, Richtlinien, Quellcode, System-of-Record-Datenbanken.
    • Hilfreich: Slack-Threads, Wikiseiten, E-Mail-Archive.

Entwerfen Sie Ihre MCP-Repositories basierend auf diesen Antworten, nicht danach, wo Ihre Daten technisch liegen. Die Kern- best practice: Kontextarchitektur folgt Verantwortung, nicht Speicherung.

2. Behandeln Sie MCP-Repositories als begrenzte Kontexte

Leihen Sie sich ein Denkmodell aus dem Domain-Driven Design: bounded contexts. In der MCP-Welt sollte ein Repository einen kohärenten Wissensabschnitt mit klarer Vereinbarung darstellen, nicht eine Sammelstelle für „alles, was wir erreichen können“.

2.1 Was ein gutes MCP-Repository repräsentiert

Denken Sie an ein Repository als benannte, verantwortliche Kontextgrenze:

  • Domainspezifisch:

    • customer-support-knowledge
    • billing-policies
    • product-specs
    • infra-runbook

  • Use-Case-spezifisch:

    • code-review-context
    • incident-response-context
    • sales-discovery-context

Innerhalb jeder Grenze können Sie mehrere zugrunde liegende Systeme vereinigen: einen Confluence-Bereich, eine Postgres-DB, einige GitHub-Repos, ein Ticketing-System. Der externe Vertrag des Repositories ist wichtiger als die interne Verkabelung.

2.2 Anti-Pattern, die Sie vermeiden sollten

  • „Alles in einem Mega-Repo“
    • Es ist verführerisch einfach. Bis Ihr Assistent während eines Produktionsvorfalls HR-Policy-Antworten gibt.
  • Datenquellen-geformte Repositories
    • confluence-repo, salesforce-repo, github-repo
    • Diese spiegeln Ihre Infrastruktur wider, nicht die kognitiven Aufgaben, die Ihr Assistent ausführt.
  • Ein-Repo-pro-Tabelle oder pro-Microservice
    • Zu stark fragmentierter Kontext erschwert Orchestrierung und Relevanzbewertung unnötig.

Faustregel: Ein Repository sollte so benannt sein, wie das Verantwortungsgebiet eines menschlichen Experten benannt würde. Wenn Sie es nicht vernünftigerweise einer Person zuordnen könnten, ist die Abgrenzung wahrscheinlich falsch.

3. Modellieren Sie Kontext als „Verträge“, nicht als „Pipelines“

Die meisten Skalierungsschmerzen entstehen, wenn man in Begriffen von Pipelines (wie Daten fließen) statt Verträgen (welche Garantien ein Repository seinen Konsumenten gibt) denkt.

Ein MCP-Repository sollte drei vertragliche Fragen beantworten:

  1. Was kann ich zuverlässig bereitstellen?

    • „Gibt man mir eine interne Ticket-ID, kann ich alle zugehörigen Tickets, den Kundenplan und die letzten drei Eskalationen liefern.“
    • „Gibt man mir einen Funktionsnamen, kann ich seine Implementierungen und die neuesten Commit-Nachrichten liefern.“

  2. Wie frisch ist es — ehrlich gesagt?

    • „Innerhalb von 60 Sekunden nachdem die Quelle-of-Truth sich geändert hat.“
    • „Täglich um 03:00 UTC.“
    • „Bei jedem Deploy.“

  3. Wie vollständig ist es?

    • „Erfasst alle aktiven Kundenkonten.“
    • „Erfasst nur Rechenzentren in Region X.“
    • „Beinhaltet Richtlinien nach 2022; vorherige könnten unvollständig sein.“

Dokumentieren Sie diese in einem Format, auf das Ihre Orchestrierungsschicht und Prompts verweisen können. Verstecken Sie sie nicht in einer README; machen Sie sie als maschinenlesbare Metadaten sichtbar, die Modell und Tools sehen können.

4. Entwerfen Sie Retrieval um Fragen, nicht um Dokumente

Kontextuelle Daten zu skalieren bedeutet weniger, mehr zu speichern, als vielmehr klüger abzurufen. Bei MCP heißt das, Repositories und Tools um Fragenklassen statt naives Dokumentensuchen zu designen.

4.1 Klassifizieren Sie die Fragen, die Ihr System tatsächlich sieht

Für jedes Repository notieren Sie 5–10 Fragetypen, in denen es besonders gut sein sollte:

  • Für customer-support-knowledge:

    • „Was ist die aktuelle Richtlinie für X?“
    • „Was hat sich am Plan Y im letzten Quartal geändert?“
    • „Wie mache ich Z im Produkt Q?“

  • Für product-specs:

    • „Welche Einschränkungen oder Limits gelten für diesen Endpunkt/Feature?“
    • „Welche Versionen unterstützen Fähigkeit R?“
    • „Welche bekannten Breaking Changes gibt es in Bezug auf S?“

Dann entwerfen Sie Retrieval-APIs für diese Klassen, statt einen einzigen „search“-Endpunkt. Oft laufen sie auf eine kleine Menge strukturierter Abfragen plus einen nachgelagerten Schritt zur semantischen Erweiterung hinaus.

4.2 Nutzen Sie strukturiertes Retrieval, bevor Sie zu Embeddings greifen

Embeddings sind mächtig, aber im großen Maßstab werden sie teuer und rauschanfällig, wenn sie nicht in Struktur verankert sind. Das zuverlässige Muster:

  1. Filtern und eingrenzen mit Struktur
    • Organisation, Region, Plan, Produktlinie, Version, Last-Updated-Timestamp.
  2. Rangieren und verfeinern mit semantischer Ähnlichkeit
    • Erst nachdem Sie die Kandidatenmenge auf etwas Handhabbares reduziert haben.
  3. Zusammenfassen und normalisieren für das Modell
    • Einheitliche Feldnamen, konsistente Einheiten und explizite Einschränkungen („Daten können veraltet sein“).

Hier glänzen MCP-Repositories: Sie lassen Sie strukturierte Filter und semantische Suche unter einem konzeptionellen Dach halten, mit klar definierten Werkzeugen oder Endpunkten für jedes.

5. Partitionieren Sie Kontext für Performance und Sicherheit

Einer der effektivsten Skalierungshebel ist Kontextpartitionierung — zu entscheiden, was niemals im selben Repository oder Prompt landen darf.

5.1 Partitionieren nach Sensitivität und Richtlinie

Öffentliche Dokumente, interne Richtlinien und eingeschränkte juristische Inhalte in einer Domäne zu mischen, ist ein Problem. Stattdessen:

  • Erstellen Sie Sensitivitätsstufen:

    • public-docs
    • internal-standard
    • restricted-legal
    • restricted-financial

  • Kodieren Sie Stufenbewusstsein in:

    • Prompt-Vorlagen („Sie dürfen internal-standard und public-docs verwenden; fragen Sie niemals restricted-* ohne explizite Anweisung.“)
    • Tool-Metadaten (Zugriffsflags, Audit-Level).
    • Repository-weit gültige Zugriffskontrolle.

Machen Sie es unmöglich — selbst in einem falsch konfigurierten Prompt — dass das Modell unbeabsichtigt die falsche Stufe heranzieht.

5.2 Partitionieren nach Latenzanforderungen

Einige Quellen müssen nicht in Echtzeit sein und sollten das auch nicht vortäuschen:

  • Niedrige Latenz / hohe Volatilität

    • Aktive Tickets, Live-Metriken, Bestellstatus.
    • Halten Sie diese in dedizierten Repositories mit strikten SLOs.

  • Hohe Latenz / niedrige Volatilität

    • Historische Changelogs, Handbücher, Archivwissen.
    • Täglich oder wöchentlich aktualisieren; keine Sorge um Sekunden.

Wenn Sie diese bündeln, wird Ihre gesamte Kontext-Pipeline an die schnellste Anforderung angepasst — das ist verschwenderisch und brüchig.

6. Standardisieren Sie Kontext-Shapes, nicht nur Formate

Sie werden unweigerlich Kontext aus Dutzenden Systemen aggregieren. JSON ist nicht Ihr Problem; die Shape ist es.

6.1 Definieren Sie eine kleine Anzahl von kanonischen Kontexttypen

Beispiele, die in vielen Organisationen gut funktionieren:

  • PolicyContext

    • id, title, effective_from, effective_to, jurisdiction, product, risk_level, body_text

  • IncidentContext

    • id, severity, status, started_at, resolved_at, services_impacted, customer_impact, timeline

  • CustomerContext

    • id, segment, plan, lifetime_value, support_tier, recent_activity_summary

  • CodeContext

    • repo, path, language, symbols, entrypoints, tests, last_updated, owner_team

Jedes MCP-Repository sollte Kontext als eine dieser Shapes ausliefern, selbst wenn es intern wild verschiedenste Quellen abfragt.

6.2 Normalisieren Sie Einheiten, Zeit und Identität

Wenn ein Repository „GB“ und ein anderes „MiB“ sagt, wird der Assistent heimlich auf nicht offensichtliche Weise Fehler machen. Gleiches gilt für Zeitzonen oder Benutzer-IDs.

Verankern Sie Normalisierung als Teil des Repository-Vertrags, sodass jedes konsumierende Tool sich auf Folgendes verlassen kann:

  • Standardzeitzone (z. B. UTC)
  • Standard-Numerikeinheiten (z. B. Byte, Sekunden, Cent)
  • Stabile Identifikatoren über Systeme hinweg (z. B. kanonische customer_id, nicht plattformspezifische IDs)

Sie können kontextuelle Intelligenz nicht skalieren, wenn jeder Prompt heimlich Datenbereinigung per Hand macht.

7. Machen Sie Aktualität explizit und auditierbar

Im großen Maßstab wird die größte Frage weniger „Kann ich das Richtige finden?“ als „Wie alt ist diese Antwort?“

7.1 Hängen Sie Aktualitäts-Metadaten an jedes Kontextstück

Für jedes abgerufene Kontextstück fügen Sie immer bei:

  • source_system
  • source_last_updated_at (aus der Quelle)
  • repository_last_synced_at (vom MCP-Adapter)
  • confidence_in_freshness (einfach low/medium/high reicht oft)
  • Optional: expected_update_cycle („hourly“, „daily“, „on deploy“)

Trainieren Sie dann Ihre Prompt-Patterns darauf, diese Felder offenzulegen und darüber nachzudenken:

„Wenn Sie den folgenden Kontext verwenden, achten Sie darauf, wie aktuell er ist. Bevorzugen Sie Daten mit dem jüngsten source_last_updated_at. Wenn älter als 30 Tage und die Frage finanzielle oder rechtliche Entscheidungen betrifft, geben Sie an, dass die Informationen veraltet sein könnten, und schlagen Sie nächste Schritte zur Verifikation vor.“

7.2 Überwachen Sie Staleness als erstklassiges SLO

Verfolgen Sie pro Repository:

  • Prozentsatz der Antworten, die auf Kontext basieren, der älter ist als Ihre Aktualitätsschwelle.
  • Durchschnittliche Verzögerung zwischen Quell-Updates und Repository-Sync.
  • Spike-Erkennung bei „stale-context“-Beschwerden von Nutzern.

Protokollieren Sie jede Abfrage mit einem Freshness-Profil und führen Sie es in Ihren Observability-Stack. Veralterung ist ein betriebliches Problem, kein LLM-Problem.

8. Bauen Sie kontextorientierte Zugriffskontrolle

Das Skalieren kontextueller Daten bedeutet, Risiken zu skalieren. MCP-Repositories sind häufig Ihre konzentrierteste Ablage von „Dingen, die eine KI sagen kann und die Ihnen schaden könnten.“

8.1 Behandeln Sie Repositories als Policy-Subjekte

Anstatt in jedem Adapter dateibasierte ACLs anzuflicken, definieren Sie Zugriff als:

  • „Assistent X darf Repositories A und B abfragen, aber nicht C.“
  • „Tools im Workflow Y dürfen nur public-docs und internal-standard Repositories sehen.“
  • „Nur Human-in-the-Loop-Flows dürfen restricted-legal berühren.“

Ihr vorhandenes IAM (oder eine dedizierte Policy-Engine) sollte Repository-ID als erstklassigen Ressourcentyp behandeln. Der tatsächliche zugrundeliegende Speicher erbt diese Haltung.

8.2 Protokollieren Sie eine Kontext-Audit-Trail

Für jede Interaktion protokollieren Sie:

  • Welche Repositories konsultiert wurden.
  • Welche Tools innerhalb jedes Repositories aufgerufen wurden.
  • Welche Identifikatoren für Lookup verwendet wurden (Ticket-ID, Kunden-ID, Repo-Pfad).
  • Einen Digest oder Hash des abgerufenen Inhalts, nicht notwendigerweise den vollen Inhalt.

Nutzen Sie dieses Log, um zwei schmerzhafte, aber unvermeidliche Fragen zu beantworten:

  • „Warum hat der Assistent das gesagt?“
  • „Haben wir jemals Kategorie X an Persona Y offengelegt?“

9. Halten Sie menschliches Feedback direkt am Kontext angeschlossen

Menschliches Feedback dient nicht nur dem Training des Assistenten; es ist kritisch für das Tuning der Repositories selbst.

9.1 Lassen Sie Benutzer „Falsch wegen Kontext“ markieren

Designen Sie Feedback-UIs mit mindestens drei Gründen:

  • „Die Antwort hat wichtigen Kontext ausgelassen, der irgendwo existiert.“
  • „Die Antwort hat den falschen oder veralteten Kontext verwendet.“
  • „Die Antwort hat Informationen erfunden, die nirgendwo existieren.“

Jeder dieser Punkte weist auf unterschiedliche Maßnahmen auf Repository-Ebene hin:

  • Fehlender Kontext → Ingestionslücken, Partitionierungsprobleme.
  • Falsch/veraltet → Sync-Zeitplan, Kanonquelle-Verwirrung.
  • Erfindung → Retrieval zu breit, Mangel an negativen Beispielen in Prompts.

9.2 Verkoppeln Sie Feedback mit Repository-Metriken

Aggregieren Sie Feedback nach Repository-Name und nach Tool- oder Abfragetyp innerhalb dieses Repositories. Verfolgen Sie dann:

  • Genauigkeitstrends pro Repository.
  • Welche Fragenklassen die höchsten Fehlerquoten haben.
  • Ob Veralterung, nicht Retrieval, das Kernproblem ist.

Das erlaubt Ihnen, operative Verbesserungen an MCP-Repositories mit der gleichen Disziplin zu priorisieren, die Sie für APIs anwenden würden, auf die Benutzer täglich angewiesen sind.

10. Bild: Die Realität der Informationsinfrastruktur im großen Maßstab

Image

Photo by Umberto on Unsplash

11. Planen Sie für Ausfall: Timeouts, Degradation und Fallbacks

Kontextsysteme fallen anders aus als traditionelle APIs. Meistens erhalten Sie keinen sauberen 500-Fehler; Sie bekommen Stille oder partielle Antworten.

11.1 Etablieren Sie Repository-weit SLIs

Definieren Sie für jedes MCP-Repository:

  • P99-Latenz für typische Abfragen.
  • Erfolgsrate für Retrieval (nicht-leere, gut geformte Antworten).
  • Abdeckung wichtiger Entitäten (z. B. % der aktiven Kunden, die vertreten sind).

Stellen Sie diese Metriken so bereit, dass Ihre Orchestrierungsschicht Entscheidungen treffen kann wie:

  • „Wenn das billing-policies-Repository degradiert ist, schalte den Assistenten in einen Modus, in dem er nur generische Hinweise anzeigt und an einen Menschen weiterleitet.“

11.2 Entwerfen Sie Fallback-Modi explizit

Überlassen Sie Fallback-Verhalten nicht dem Zufall oder generischem „wenn Tool fehlschlägt, entschuldige dich“. Stattdessen:

  • Fallback 1: Reduzierter Kontextmodus

    • Verwenden Sie nur lokale, gecachte Zusammenfassungen oder historisch stabile Dokumente.
    • Kennzeichnen Sie in der Antwort deutlich, dass nur eingeschränkter Kontext verfügbar war.

  • Fallback 2: Aufgab ablehnung mit Eskalation

    • Für risikoreiche Domänen bevorzugen Sie eine saubere, sofortige Übergabe an einen Menschen.

  • Fallback 3: Nutzerinitiiertes Kontext-Upload

    • Ermöglichen Sie einem Nutzer, fehlende Dokumente einmalig in eine Konversation einzufügen oder hochzuladen, während diese für zukünftige Ingestion markiert werden.

Planen Sie, wie Ihr System reagiert, wenn ein Repository langsam, veraltet oder nicht erreichbar ist — genauso, wie Sie für Core-API-Ausfälle planen.

12. Überladen Sie das Modell nicht; kuratieren Sie den Prompt

Kontextuelle Daten zu skalieren heißt nicht, bei jedem Aufruf mehr hineinzuschütten. Es heißt, wählerisch zu sein.

12.1 Respektieren Sie feste Kontextfenster

Selbst mit großen Kontextfenstern führt unkontrolliertes Vollladen zu:

  • Erhöhter Latenz.
  • Höheren Kosten.
  • Mehr Halluzinationen durch widersprüchlichen oder verrauschten Text.

Nutzen Sie Ihre MCP-Repositories, um vorab zu aggregieren und vorab zu interpretieren, wo immer möglich:

  • Zusammenfassungen jüngster Vorfälle, nicht die kompletten Root-Cause-Dokumente.
  • Richtliniendigests pro Kundensegment, nicht alle Richtlinien auf einmal.
  • Orchestrierungslogik, die ein relevantes Repository für eine enge Frage auswählt.

12.2 Machen Sie Quellen-Grenzen im Prompt sichtbar

Wenn Sie mehrere Kontextstücke senden, behalten Sie sie beschriftet und getrennt bei:

[Source: billing-policies, doc_id=policy-2024-07-01]
...text...

[Source: customer-support-knowledge, doc_id=macro-RETENTION-03]
...text...

Weisen Sie das Modell dann an:

„Wenn Quellen widersprechen, bevorzugen Sie billing-policies gegenüber customer-support-knowledge bei Abrechnungsfragen. Nennen Sie immer, wenn Sie Konflikte bemerken.“

Das ist trivial zu implementieren, sobald Ihre Repositories konsistente Metadaten und Shapes liefern.

13. Governance: Entscheiden Sie, wer jedes Repository besitzt

Das Skalieren von MCP-Repositories ist teilweise eine technische Herausforderung und teilweise ein Governance-Problem.

13.1 Ordnen Sie klare Eigentümerschaft zu

Für jedes Repository benennen Sie:

  • Einen technischen Eigentümer
    • Verantwortlich für Verfügbarkeit, Performance, Sync-Pipelines.
  • Einen Inhalts-Eigentümer
    • Verantwortlich für Korrektheit, Abdeckung und Stilllegung veralteten Materials.

Das sollten tatsächliche Teams sein, keine heldenhaften Einzelpersonen: Billing Platform, Security Engineering, Developer Experience usw.

13.2 Setzen Sie eine Lifecycle-Policy

Repos verfallen wie Code. Standardisieren Sie:

  • Erstellung
    • Genehmigungsprozess, Namenskonventionen, anfängliche Vertragsdefinition.
  • Change-Management
    • Wie neue Quellsysteme hinzugefügt werden.
    • Wie hochriskante Inhaltsaktualisierungen geprüft werden.
  • Stilllegung
    • Bedingungen, unter denen ein Repository deprecated wird und wie sein Vertrag migriert wird.

Ohne das wachen Sie in einem Jahr mit einem Wald halbverlassener Kontext-Silos auf, denen niemand vertraut und die jeder fürchtet anzufassen.

14. Versionieren Sie Wissen so sorgfältig wie Code

Modelle ändern sich. Prompts ändern sich. Richtlinien ändern sich. Wenn Sie den Kontext, auf den diese Dinge angewiesen sind, nicht versionieren, wird Debugging zum Ratespiel.

14.1 Führen Sie Repository-Versionen ein

Unterstützen Sie weiche Versionen wie:

  • billing-policies@2024-Q1
  • product-specs@v3.2
  • infra-runbook@post-incident-1342

Ihre Tools und Prompts können dann festlegen auf:

  • Einen beweglichen Track (latest-stable) für niedriges Risiko und hohe Flexibilität.
  • Eine fixe Version für risikoreiche Entscheidungen (Regulierung, Recht, Sicherheit).

14.2 Bewahren Sie historische Snapshots zugänglich auf

Für Audits und Untersuchungen:

  • Behalten Sie eine Historie dessen, wie jedes Repository zu wichtigen Zeitpunkten aussah.
  • Können Sie rekonstruieren: „Was hätte der Assistent am 1. März gesehen, als er diese Anleitung erzeugte?“

Das kann so simpel sein wie tägliche Exporte oder so strukturiert wie unveränderlich versionierte Wissensgraphen, aber das Prinzip bleibt: verlieren Sie nicht Ihre eigene Vergangenheit.

15. Halten Sie die Anzahl der Repositories überschaubar

Fragmentierung ist ebenso gefährlich wie Zentralisierung. Es gibt in vielen Organisationen eine grobe Sweetspot:

  • Frühe Phase: 3–5 Repositories
    • Produktdokumentation, Support-Dokumente, interne Richtlinien, Code-Kontext, Infra-Kontext.
  • Wachstumsphase: 8–15 Repositories
    • Nach Domäne und Sensitivitätsstufe aufgesplittet, aber jedes sinnvoll groß halten.

Widerstehen Sie dem Druck für:

  • Ein-Repo-pro-Team: führt zu überlappender Abdeckung, inkonsistenten Verträgen.
  • Ein-Repo-pro-Datenbank: erzeugt Integrationssprawl mit geringem Nutzen für Nutzer.

Designen Sie für Auffindbarkeit: Ein Mensch sollte die Liste der Repositories durchlesen können und intuitiv verstehen, wann jedes genutzt wird.

16. Machen Sie MCP-Repositories zu erstklassigen Elementen Ihrer Engineering-Kultur

Schließlich funktioniert das Skalieren kontextueller Daten am besten, wenn Teams anfangen, MCP-Repositories als erwarteten Teil der Feature-Auslieferung zu denken.

Integrieren Sie sie in:

  • Design-Dokumente:

    • „Welches MCP-Repository wird dieses Feature unterstützen?“
    • „Welche neue Kontext-Shape brauchen wir, falls überhaupt?“

  • Definition of Done:

    • „Wurde das passende Repository aktualisiert oder erweitert?“
    • „Sind Aktualität und Sync-Pattern konfiguriert?“

  • Post-Incident-Reviews:

    • „Hat fehlender oder veralteter Kontext zum Vorfall beigetragen?“
    • „Brauchen wir ein neues Repository oder eine Änderung an einem bestehenden?“

Wenn MCP-Repositories als zentrale Infrastruktur und nicht als Nebenbeigabe für AI-Experimente behandelt werden, werden sie das Rückgrat jeder intelligenten Fähigkeit, die Sie später hinzufügen.

Das Skalieren kontextueller Daten mit MCP bedeutet nicht, dem Modell mehr zu füttern; es bedeutet, bewusste Entscheidungen darüber zu treffen, was offengelegt wird, wie es geformt ist und wer dafür verantwortlich ist. Wenn Sie das gut machen, hört das Modell auf, über Ihre Welt zu raten, und beginnt, in ihr mit derselben Zuversicht und Klarheit zu arbeiten, die Ihre besten Mitarbeiter jeden Tag mitbringen.

How to Scale MCP to 100+ Tools - ApX Machine Learning Building Scalable AI Tool Servers with Model Context Protocol (MCP … The MCP Security Survival Guide: Best Practices, Pitfalls, and Real … Making MCP work with fragmented data: Why harmonization is the … Need advice on orchestrating 100s of MCP servers at scale - Reddit