Erste Schritte

Erste Schritte für MCPlet-Hosts und Tool-Autoren

Dieser Leitfaden verdichtet MCPlet v202603-03 zu einem Implementierungspfad: das richtige Host-Profil wählen, Tools korrekt klassifizieren, Code-First-Metadaten bereitstellen und dort stärkere Durchsetzung anwenden, wo Aktionen Nebenwirkungen verursachen können.

Version v202603-03
Betreut von MCPlet Working Group
Normative Quelle Roher Markdown-Entwurf
Aktualisiert 2026-04-01

Implementierungspfad

  1. Entscheiden Sie, ob Ihr Host ein WebUI Profile oder ein Agent Profile ist. Dies bestimmt, ob MCP Apps-Rendering Teil Ihrer Laufzeitumgebung ist und wie Bestätigungsabläufe implementiert werden.
  2. Klassifizieren Sie jedes Tool als read, prepare oder action. Dies ist nicht nur Dokumentation, sondern Teil des Sicherheitsmodells.
  3. Registrieren Sie Code-First-Metadaten in _meta, einschließlich mcpletType, visibility und der optionalen Felder ui, auth und pool.
  4. Stellen Sie einen Tool-Ergebnisschema-URI bereit, damit der Host strukturierte Ergebnisse validieren und nachgelagerte Konsumenten Ausgaben sicher verarbeiten können.
  5. Fordern Sie strenge Passkey-Durchsetzung, wenn eine modellsichtbare Aktion irreversible Nebenwirkungen auslösen kann.
Wenn Sie sich nur eine Regel merken: Behandeln Sie MCPlet niemals als Ersatz für MCP. MCP ist die Protokollschicht; MCPlet ist die Konventionsschicht, die Tool-Verhalten auf sicherere, überprüfbare Einheiten einengt.

1. Host-Profil auswählen

Verwenden Sie WebUI Profile, wenn Sie MCP Apps UI rendern. Verwenden Sie Agent Profile, wenn Ihr Host eine Orchestrierungsschicht aus spezialisierten Agenten mit einem extern konfigurierten LLM ist.

2. Das Tool klassifizieren

Wählen Sie read für sichere Abfragen, prepare für stufenweise Validierung und action für irreversible Nebenwirkungen, die engere Kontrolle erfordern.

4. Modellsichtbare Aktionen schützen

Wenn eine Aktion für das Modell sichtbar ist, fordern Sie explizites Abfangen und starke Bestätigung, vorzugsweise mit strikter Passkey-Durchsetzung.

MCP, MCP Apps und MCPlet auf einen Blick

Schicht Hauptrolle Was es Ihnen bietet Was es Ihnen nicht bietet
MCP Protokoll Tool- und Ressourcentransport, Erkennung und Aufruf-Semantik. Intent-Modellierung, Aktionssicherheitsrichtlinie oder meinungsstarke Tool-Klassifizierung.
MCP Apps UI-Integration Host-View-Rendering, iframe-Lebenszyklus und App-Bridge-Verhalten. Business-Intent-Grenzen, Metadaten-Sicherheitsregeln oder Auth-Konventionen.
MCPlet Konventionsprofil Einzelne Intent-Einheiten, read/prepare/action-Klassifizierung, Sichtbarkeitsbeschränkungen, Auth-Anforderungen und host-verwaltete Sicherheitsgrenzen. MCP-Transport, generisches Laufzeitverhalten oder ein obligatorisches Frontend-Framework.

Minimales Code-First-Metadaten-Beispiel

Dieses Beispiel zeigt die Felder, über die die meisten Implementierungen beim Mapping eines Tools in MCPlet zuerst nachdenken sollten.

{
  "_meta": {
    "mcpletType": "prepare",
    "visibility": ["model", "app"],
    "mcpletToolResultSchemaUri": "mcplet://tool-result-schema/check_order",
    "ui": {
      "resourceUri": "ui://orders/check.html",
      "displayMode": "inline"
    }
  }
}

Ändern Sie für irreversible Operationen die Klassifizierung zu action und fügen Sie _meta.auth mit strengerer Durchsetzung hinzu.

Wann MCPlet verwenden und wann nicht

MCPlet verwenden, wenn

  1. Sie einen überprüfbaren Business-Intent pro Tool wünschen.
  2. Sie den Host benötigen, um klare Modell-versus-App-Grenzen durchzusetzen.
  3. Sie einen Code-First-Metadatenvertrag über MCP wünschen.

MCPlet nicht verwenden, wenn

  1. Ihre Tool-Oberfläche absichtlich breit und vielseitig ist.
  2. Sie nach einem Ersatzprotokoll statt einem Konventionsprofil suchen.
  3. Ihr Host keine Zustände, Abfangungen oder Sicherheitsrichtlinien verwalten kann.