@clicbase/mcp 0.1.4 → 0.2.0

package/README.md

@@ -18,6 +18,38 @@ Outils :
 - `enable_realtime` — active le temps réel sur une table.
 - `set_oauth_provider` — configure Google OAuth.
 - `set_email_smtp` — configure un SMTP (sinon SMTP interne Clicbase par défaut).
+- `list_site_files` — liste les fichiers d'un site heberge (nom, taille, date).
+- `read_site_file` — rend le contenu d'UN fichier, en base64 cote API, decode cote outil.
+- `clicbase_conventions` — les regles de la plateforme : policies RLS, droits, PostgREST.
+
+## Les fichiers d'un site
+
+Jusqu'a la 0.2.0, une cle pouvait ECRASER les fichiers d'un site sans pouvoir
+les lire : l'interdit etait pose du mauvais cote, puisque ecrire est
+strictement plus dangereux que lire. La seule issue etait un mot de passe SFTP,
+c'est-a-dire un secret durable colle dans une conversation pour contourner un
+endpoint absent.
+
+```
+list_site_files(site_id)               -> un niveau de la racine publique
+list_site_files(site_id, "assets")     -> on descend
+read_site_file(site_id, "index.html")  -> le contenu, decode
+```
+
+L'id du site vient de `GET /api/v1/admin/sites`.
+
+⚠️ `list_site_files` est une LECTURE, `read_site_file` est un SECRET. Le nom
+d'un fichier revele une structure ; son contenu peut porter des identifiants
+dans un `config.php` ou un `settings.js`. Le second disparait donc du mode
+restreint, comme `get_credentials`.
+
+⚠️ LES FICHIERS CACHES SONT HORS D'ATTEINTE, a tout niveau : `.env` comme
+`assets/.env`. Le serveur refuse tout segment commencant par un point, aussi
+bien au depot qu'a la lecture. Cette garde existait pour empecher qu'ils soient
+SERVIS par le serveur web ; elle protege exactement le bon flanc.
+
+Plafond : 2 Mo cote API, 256 Ko cote outil. Au-dela, le telechargement du
+tableau de bord ou le SFTP.
 
 ## Lecture seule
 

package/clicbase-mcp.mjs

@@ -274,6 +274,63 @@ outils.tool(
   async ({ name, ...cfg }) => { try { return out(await call(name, "/email/config", "POST", cfg)); } catch (e) { return fail(e); } },
 );
 
+// Les fichiers d'un site heberge. `admin` cible l'API d'administration, la ou
+// `call` parle a la base d'un projet : deux surfaces differentes.
+async function admin(chemin, methode = "GET") {
+  const base = API_LECTURE.replace(/\/projects$/, "");
+  const res = await fetch(`${base}${chemin}`, {
+    method: methode,
+    headers: { authorization: `Bearer ${CLE}` },
+  });
+  if (!res.ok) {
+    const e = await lireEchec(res);
+    throw new Error(`Clicbase ${res.status} — ${expliquer(res.status)} ${e.detail}`);
+  }
+  return res.json();
+}
+
+outils.tool(
+  "list_site_files",
+  "Liste les fichiers d'un site heberge (nom, dossier ou non, taille, date). `dossier` pour descendre d'un niveau. L'id du site vient de GET /sites.",
+  { site_id: z.string(), dossier: z.string().optional() },
+  async ({ site_id, dossier }) => {
+    try {
+      const q = dossier ? `?dossier=${encodeURIComponent(dossier)}` : "";
+      return out(await admin(`/sites/${encodeURIComponent(site_id)}/files${q}`));
+    } catch (e) {
+      return fail(e);
+    }
+  },
+);
+
+outils.tool(
+  "read_site_file",
+  "Rend le contenu d'UN fichier d'un site heberge, en base64. Plafond 2 Mo. Les fichiers caches (.env, .git) sont refuses par le serveur, a tout niveau.",
+  { site_id: z.string(), chemin: z.string() },
+  async ({ site_id, chemin }) => {
+    try {
+      const d = await admin(
+        `/sites/${encodeURIComponent(site_id)}/files?chemin=${encodeURIComponent(chemin)}`,
+      );
+      // ⚠️ ON DECODE ICI, ET ON PLAFONNE PLUS BAS QUE L'API. Rendre du base64 a
+      // un modele lui fait depenser son contexte a le decoder, souvent mal. Et
+      // 2 Mo de source dans une conversation ne servent personne : au-dela de
+      // 256 Ko on refuse en le disant, plutot que de noyer la session.
+      const brut = Buffer.from(String(d.contenu ?? ""), "base64");
+      if (brut.byteLength > 256 * 1024) {
+        return fail(
+          new Error(
+            `Fichier de ${brut.byteLength} octets : trop gros pour une conversation. Telecharge-le par le tableau de bord ou par SFTP.`,
+          ),
+        );
+      }
+      return out({ chemin: d.chemin, octets: d.octets, contenu: brut.toString("utf8") });
+    } catch (e) {
+      return fail(e);
+    }
+  },
+);
+
 // ⚠️ LE MODE RESTREINT S'ANNONCE, SUR LA SORTIE D'ERREUR. Un serveur qui
 // retire des outils en silence se decouvre en pleine session : l'assistant
 // cherche une fonction qui devrait exister, ne la trouve pas, et conclut que le

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@clicbase/mcp",
-  "version": "0.1.4",
+  "version": "0.2.0",
   "type": "module",
   "bin": {
     "mcp": "clicbase-mcp.mjs",

package/portee.mjs

@@ -48,6 +48,14 @@ export const OUTILS = {
   // restreint qui en a le plus besoin, puisqu'il ne reste alors que trois
   // outils et qu'un assistant doit deviner le reste.
   clicbase_conventions: "lecture",
+  // --- fichiers d'un site heberge ---
+  // ⚠️ LISTER EST UNE LECTURE, LIRE EST UN SECRET. Le nom et la taille d'un
+  // fichier revelent une structure ; son CONTENU peut porter des identifiants,
+  // dans un config.php ou un settings.js. Meme raisonnement que
+  // get_credentials : il ne modifie rien, et il rend quand meme les clefs de
+  // la maison. Les fichiers caches, eux, sont deja impossibles cote serveur.
+  list_site_files: "lecture",
+  read_site_file: "secret",
 };
 
 /** Ce qu'on garde en lecture seule. */

package/savoir.mjs

@@ -35,7 +35,7 @@ SIX PIÈGES QUI NE LÈVENT AUCUNE ERREUR. Ils répondent tous « 200 OK ».
 5. Une fonction Edge renvoie \`{ status, body }\`, jamais \`new Response(...)\`.
 6. Deux authentifications sans rapport coexistent. Celle du PROJET (tes utilisateurs finaux) vit dans le schéma \`auth\` de cette base et alimente \`auth.uid()\` dans les policies. Celle de la PLATEFORME (le compte Clicbase) ne s'écrit jamais dans une policy.
 
-CE QUI N'EXISTE PAS, ET QUE DEUX ASSISTANTS ONT DEJA INVENTE. Il n'y a AUCUN registre Docker : ni \`docker login\`, ni \`docker pull\`, ni \`registry.*.clicbase.com\`. Ne devine aucun nom d'hote. Ce serveur MCP ne rend pas le code source d'un site heberge : pour recuperer des fichiers, c'est le SFTP du tableau de bord ou son gestionnaire de fichiers, et l'API d'administration ne fait que les ECRIRE (POST /sites/<id>/files), jamais les lire.
+CE QUI N'EXISTE PAS, ET QUE DEUX ASSISTANTS ONT DEJA INVENTE. Il n'y a AUCUN registre Docker : ni \`docker login\`, ni \`docker pull\`, ni \`registry.*.clicbase.com\`. Ne devine aucun nom d'hote. Les fichiers d'un site heberge se lisent par \`list_site_files\` et \`read_site_file\`, et s'ecrivent par POST /sites/<id>/files. Inutile de reclamer un mot de passe SFTP pour cela : le SFTP reste utile pour un transfert volumineux, pas pour consulter. Les fichiers CACHES sont refuses a tout niveau, \`.env\` et \`.git\` compris : ils ne peuvent ni etre deposes ni etre lus. \`read_site_file\` est absent en lecture seule, parce qu'un source peut porter des identifiants dans un fichier non cache.
 
 APPELS REST : en-têtes \`apikey\` ET \`Authorization: Bearer\`, la même clé dans les deux. Filtres dans l'URL, façon PostgREST : \`?select=id,title&status=eq.published&order=created_at.desc\`.