Zum Inhalt springen

Pattern: Vorhandene MCP-Tools wrappen

Wenn du bereits einen funktionierenden MCP-Server hast, ist der schnellste Weg zu einer Selu-Capability oft ein Wrapper und kein Rewrite.

Diese Seite zeigt das Muster anhand von bring-mcp für Bring!-Einkaufslisten und dem Beispielagenten selu-agent-bring-shopping.

Nutze einen Wrapper, wenn:

  • der bestehende MCP-Server stabil ist und bereits getestet wurde
  • du schnell ausliefern willst und möglichst wenig eigene Integrationslogik schreiben möchtest
  • Selu Tools dynamisch erkennen soll, statt Tool-Schemata manuell in manifest.yaml zu kopieren
  1. Selu ruft deine Capability per gRPC über Invoke auf.
  2. Für Discovery ruft Selu das Discovery-Tool list_tools der Capability auf.
  3. Der Wrapper startet einen MCP-Subprozess wie bring-mcp und leitet die Discovery an MCP tools/list weiter.
  4. Selu speichert die erkannten Tools und gleicht Richtlinien ab.
  5. Normale Tool-Aufrufe werden über MCP tools/call weitergereicht.

So bleibt die Kompatibilität an der Selu-Grenze bei gRPC erhalten, während die internen MCP-Teile unverändert weiterverwendet werden.

  • Ordnerselu-agent-bring-shopping/
    • agent.yaml
    • agent.md
    • Ordnercapabilities/
      • Ordnerbring-shopping/
        • manifest.yaml
        • prompt.md
        • Ordnercontainer/
          • Dockerfile
          • requirements.txt
          • capability.proto
          • server.py
  1. Den Agenten deklarieren

    agent.yaml
    id: bring-shopping
    name: Bring Shopping Assistant
    routing: inline
    session:
    trigger: mention
    idle_timeout_minutes: 30
    memory:
    policy: none
    top_k: 0
  2. Dynamische Capability-Tools in manifest.yaml verwenden

    Statt die Tool-Liste fest einzutragen, aktivierst du dynamische Discovery:

    capabilities/bring-shopping/manifest.yaml
    id: bring-shopping
    class: tool
    image: selu-cap-bring-shopping:latest
    tool_source: dynamic
    discovery_tool_name: list_tools
    tools: []
    credentials:
    - name: MAIL
    scope: user
    required: true
    description: "Bring account email"
    - name: PW
    scope: user
    required: true
    description: "Bring account password"
  3. Eine Brücke bauen, die Invocation und Discovery unterstützt

    Dein Wrapper muss Folgendes unterstützen:

    • normale Tool-Aufrufe über tools/call
    • Discovery-Aufrufe über tools/list, nach außen als Selu-list_tools
    capabilities/bring-shopping/container/server.py
    if request.tool_name == "list_tools":
    bridge = McpBridge(mail_or_dummy, pw_or_dummy)
    bridge.start()
    try:
    raw = bridge.list_tools() # MCP method: tools/list
    finally:
    bridge.close()
    return InvokeResponse(result_json=json.dumps(normalize(raw)).encode("utf-8"))

    Das normalisierte Discovery-Ergebnis muss ein JSON-Array mit Objekten sein, die Folgendes enthalten:

    • name
    • description
    • input_schema
    • optional recommended_policy
  4. Laufzeitabhängigkeiten im Dockerfile verpacken

    Installiere beide Seiten:

    • Python-Abhängigkeiten für den gRPC-Server und die generierten Stubs
    • Node plus das vorgelagerte MCP-Paket bring-mcp
    capabilities/bring-shopping/container/Dockerfile
    ARG BRING_MCP_NPM_VERSION=latest
    RUN apt-get update \
    && apt-get install -y --no-install-recommends nodejs npm \
    && npm install -g "bring-mcp@${BRING_MCP_NPM_VERSION}" \
    && rm -rf /var/lib/apt/lists/*
  5. Das LLM mit prompt.md anleiten

    Füge explizite Hinweise zum Tool-Ablauf hinzu, zum Beispiel: zuerst die Standardliste auflösen, dann Einträge hinzufügen, lesen oder entfernen.

  • Credential-Passthrough: Zugangsdaten aus Selu kommen in config_json an. Mappe sie auf Umgebungsvariablen des MCP-Prozesses.
  • Standardrichtlinien für Tools: Liefere recommended_policy im Discovery-Ergebnis mit, etwa ask für verändernde Tools und allow für reine Lesezugriffe.
  • Policy-Abgleich: Selu fügt Richtlinien für neue Tools hinzu und entfernt Richtlinien für gelöschte Tools.
  • Netzwerkrichtlinien: Starte mit einer strikten Allowlist für bekannte Upstream-Hosts.
  • Fehlerbehandlung: Bewahre aussagekräftige Fehlermeldungen des Upstreams, ohne Geheimnisse in Logs zu leaken.
  • Versionen pinnen: Pinne die Version des MCP-Pakets im Dockerfile, damit keine unbeabsichtigten Breaking Changes hereinkommen.