Prise en main

Premiers pas pour les hôtes MCPlet et les auteurs d'outils

Ce guide résume MCPlet v202603-03 en un chemin d'implémentation : choisir le bon profil d'hôte, classifier les outils correctement, exposer les métadonnées code-first, et appliquer une application plus stricte là où les actions peuvent causer des effets de bord.

Version v202603-03
Maintenu par MCPlet Working Group
Source normative Brouillon Markdown brut
Mis à jour 2026-04-01

Chemin d'implémentation

  1. Choisissez si votre hôte est WebUI Profile ou Agent Profile. Cela détermine si le rendu MCP Apps fait partie de votre runtime et comment les flux de confirmation sont implémentés.
  2. Classifiez chaque outil comme read, prepare ou action. Ce n'est pas uniquement de la documentation ; c'est une partie du modèle de sécurité.
  3. Enregistrez les métadonnées code-first dans _meta, incluant mcpletType, visibility, et les champs optionnels ui, auth, et pool.
  4. Exposez un URI de schéma de résultat d'outil afin que l'hôte puisse valider les résultats structurés et que les consommateurs en aval puissent raisonner sur les sorties en toute sécurité.
  5. Exigez une application stricte des passkeys lorsqu'une action visible par le modèle peut déclencher des effets de bord irréversibles.
Si vous ne retenez qu'une règle : ne traitez jamais MCPlet comme un remplacement de MCP. MCP est la couche protocole ; MCPlet est la couche de convention qui restreint le comportement des outils en unités plus sûres et révisables.

1. Choisir le profil d'hôte

Utilisez WebUI Profile si vous affichez l'interface MCP Apps. Utilisez Agent Profile si votre hôte est une couche d'orchestration d'agents spécialisés avec un LLM configuré en externe.

2. Classifier l'outil

Choisissez read pour une récupération sûre, prepare pour une validation par étapes, et action pour les effets de bord irréversibles nécessitant un contrôle plus strict.

4. Protéger les actions visibles par le modèle

Si une action est visible par le modèle, exigez une interception explicite et une confirmation forte, de préférence avec une application stricte des Passkeys.

MCP, MCP Apps et MCPlet en un coup d'œil

Couche Rôle principal Ce qu'il vous apporte Ce qu'il ne vous apporte pas
MCP Protocole Transport, découverte et sémantique d'invocation des outils et ressources. Modélisation des intents, politique de sécurité des actions ou classification opinionnée des outils.
MCP Apps Intégration UI Rendu de la vue hôte, cycle de vie des iframes et comportement du pont applicatif. Limites d'intent métier, règles de sécurité des métadonnées ou conventions d'authentification.
MCPlet Profil de convention Unités à intent unique, classification read/prepare/action, contraintes de visibilité, exigences d'auth et limites de sécurité gérées par l'hôte. Transport MCP, comportement générique du runtime ou framework frontend obligatoire.

Exemple minimal de métadonnées code-first

Cet exemple montre les champs auxquels la plupart des implémentations devraient penser en premier lors du mappage d'un outil dans MCPlet.

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

Pour les opérations irréversibles, changez la classification en action et ajoutez _meta.auth avec une application plus stricte.

Quand utiliser MCPlet et quand ne pas l'utiliser

Utilisez MCPlet quand

  1. Vous voulez un seul intent métier révisable par outil.
  2. Vous avez besoin que l'hôte applique des limites claires entre modèle et application.
  3. Vous voulez un contrat de métadonnées code-first au-dessus de MCP.

N'utilisez pas MCPlet quand

  1. Votre surface d'outil est intentionnellement large et polyvalente.
  2. Vous cherchez un protocole de remplacement plutôt qu'un profil de convention.
  3. Votre hôte ne peut pas gérer l'état, l'interception ou la politique de sécurité.