MCP aperçu

Showly expose ses capacités aux agents de codage via le Model Context Protocol. Cette page explique le _pourquoi_ — pour le _quoi_, passez à la référence de l'outil.

Pourquoi MCP

Un simple REST API forcerait chaque agent à apprendre un flux d'authentification personnalisé, des formes de requête personnalisées et une sémantique d'erreur personnalisée. MCP résout les trois :

• Outils typés. Chaque capacité est un tool avec une entrée et une sortie de schéma JSON. L'hôte de l'agent (Claude Code, Codex) restitue automatiquement la liste d'outils pour l'utilisateur.
• Jetons de portée. Un jeton Showly MCP est lié à un espace de travail, éventuellement à un projet, à l'utilisateur autorisant lors de sa création via le flux OAuth/appareil et à un ensemble de portées d'outils. Le jeton n'accorde jamais plus que ce dont l'agent a besoin.
• Audit de première classe. Chaque appel d'outil enregistre l'identifiant client, l'action, les paramètres (avec rédaction secrète) et le résultat.

Ce que voit l'agent

Une fois que l'utilisateur a installé le client Showly MCP, l'agent voit les outils regroupés par fonctionnalité :

• Lire — list_projects, list_sites, get_site_context, get_site_files, get_preview_status
• Plan — create_change_plan
• Postuler — apply_site_patch
• Construire — create_preview, run_checks, retry_deployment
• Expédier — request_publish (ouvre un flux d'approbation humaine sur les plans avec des workflows d'approbation) ; publish_site et rollback_to_version agissent directement via un jeton de confirmation en deux étapes dans la conversation
• Inspecter — get_deployment_logs, diagnose_deployment, list_deployments, list_site_versions, diff_site_versions
• À bord — list_templates, create_site_from_template, create_site_from_html, claim_trial_site
• Transfer — request_upload_url, request_download_url (URL signées pour les fichiers volumineux qui ne doivent pas traverser le contexte du modèle)
• Nettoyer — delete_preview, delete_site

Le schéma de chaque outil rend explicite son rayon d'explosion : request_publish nécessite un deploymentId pour un aperçu prêt. Le seul verbe entièrement supprimé MCP est l'héritage rollback_deployment — il vit dans l'interface utilisateur Web derrière l'AMF améliorée. Les outils MCP affectant la production (publish_site, rollback_to_version, delete_site) n'agissent jamais au premier appel : ils renvoient un jeton de confirmation de courte durée qui doit être renvoyé lors d'un deuxième appel.

Comment les jetons sont-ils définis

Un administrateur d'espace de travail émet un jeton MCP à partir de Paramètres de l'espace de travail → MCP clients. Chaque jeton possède :

• un nom de client (donc les journaux d'audit se lisent comme "Claude Code (alice@acme)")
• une portée de projet facultative (quel projet ce client peut toucher)
• un ensemble de portée — des chaînes de portée plates (pas de niveaux, pas d'échelle d'implication), par défaut project:read, site:read, preview:read ; voir la liste complète dans Portées et jetons
• un TTL (par défaut 90 jours, max 365 jours)

Les jetons peuvent être révoqués instantanément depuis le même panneau.

Frontières

La surface MCP n'expose pas intentionnellement :

• Accès direct à la base de données.
• Valeurs des variables de l'environnement de production.
• Lectures croisées de toute nature.
• Mutations de facturation de l'espace de travail ou de gestion des utilisateurs.

Si le flux de travail de votre agent nécessite quelque chose qui ne figure pas dans cette liste, signalez un problème : la réponse est presque toujours « ajouter un outil avec une portée plus étroite », et non « ouvrir le API ».

Suivant

-Référence de l'outil — chaque outil, avec paramètres et champs d'audit.

• Portées et jetons — comment émettre, faire pivoter, révoquer.