Serveur MCP

Ce que le serveur expose

35outils MCP

8prompts

18ressources

v5.14streamable-http

Chiffres relus dans le code source à chaque génération de cette page — ils ne peuvent pas dériver de ce que le serveur expose réellement.

Identifiant: io.github.nic01asFr/gristcoder
Transport: streamable-http — 2025-03-26, sur /mcp
Image: ghcr.io/nic01asfr/grist-coder

Claude Code

claude mcp add grist-coder --transport http http://localhost:8742/mcp \
  --header "Authorization: Bearer <clé Grist>" \
  --header "X-Grist-Site: https://<instance>"

Claude Desktop

{
  "mcpServers": {
    "grist-coder": {
      "type": "http",
      "url": "http://localhost:8742/mcp",
      "headers": {
        "Authorization": "Bearer <clé Grist>",
        "X-Grist-Site": "https://<instance>"
      }
    }
  }
}

La promesse

Ce que ça change

Un document Grist contient déjà les données, les droits et le partage. Ce qui lui manque pour être une application — des écrans, de la logique, des déclencheurs — se construit ici par la conversation, et reste rangé à l'intérieur du document.

L'application vit dans le documentLes interfaces HTML/React sont rangées dans une table du document et rendues par le widget. Il n'y a pas de second hébergement à tenir : l'application voyage avec le fichier, se partage comme lui, se sauvegarde comme lui.
Publier, c'est couper le cordonUn artefact publié est figé dans le document, imports npm compilés. Il survit à l'arrêt du serveur qui l'a écrit — la publication refuse d'ailleurs tout artefact qui garderait un lien vers lui.
L'outillage suit l'avancementLes outils ne sont pas tous exposés d'emblée. Six phases dévoilent ce qui est pertinent au moment où ça l'est, ce qui empêche d'écrire du code avant d'avoir lu le schéma.
L'utilisateur final ne voit jamais l'IAIl ouvre une application et s'en sert. Le modèle, le code et les allers-retours restent du côté de celui qui construit.
Ton serveur, tes secretsUn chart Helm déploie un serveur par utilisateur sur SSPCloud Onyxia. Chacun garde sa clé, et personne n'est dépositaire des documents des autres.

En images

À quoi ça ressemble

Le widget à l'ouverture : les artefacts du document, en tuiles cliquables.

Un artefact carte et son code côte à côte : l'aperçu se rafraîchit à l'écriture.

Fonctionnalités

Ce que tu peux faire

Les quatre couches d'une application

Données (tables et formules), interface (artefacts et pages Grist), logique (SQL, UserActions, upsert), intégrations (webhooks vers l'extérieur). Les quatre se construisent depuis la même conversation, sans changer d'outil en cours de route.

Quand un tableur ne suffit plus, mais qu'un développement complet est hors de portée.

Un IDE dans le document

Le widget est un écran coupé en deux : l'éditeur à gauche, l'aperçu à droite. L'écriture est incrémentale — on lit le code, on remplace un fragment, on regarde. Les erreurs de rendu remontent avec leur numéro de ligne au lieu d'un échec muet.

Pour corriger une interface sans jamais quitter Grist.

Publication autonome

La publication fige l'artefact dans une section du document et compile ses imports npm. Le résultat est un widget ordinaire : il ne connaît plus le serveur, et continue de fonctionner si celui-ci disparaît.

Pour livrer quelque chose qui ne dépend plus de toi.

Un agent embarqué dans le widget

Près de 2 800 lignes de JavaScript font tourner une boucle d'agent à l'intérieur même du widget : le document peut se construire sans client MCP externe. La configuration du modèle est servie par le serveur, et la clé ne quitte jamais celui-ci.

Quand il n'y a pas de client MCP en face, juste un navigateur.

Dialogue guidé

Plutôt que deviner, l'assistant pose la question dans le widget : choix, formulaire, confirmation, import de données externes. La réponse revient dans la conversation et la construction reprend où elle en était.

Pour les décisions qu'un modèle n'a pas à prendre seul. En bêta.

Mise en ligne par utilisateur

Le chart Helm installe un serveur personnel, protégé par jeton et verrouillé sur son propriétaire au premier contact. Un connecteur OAuth 2.1 embarqué fait du serveur son propre fournisseur d'identité, ce qui évite de coller une clé d'API dans un client.

Pour mettre en ligne sans passer par un service multi-locataires.

Prise en main

Le parcours

1
Tu ajoutes le widget
Coder s'installe comme widget personnalisé sur une page du document. Il s'enregistre auprès du serveur et ouvre une session.
2
Tu décris ce que tu veux
L'assistant qualifie le besoin avant de toucher à quoi que ce soit. À ce stade, il n'a même pas accès aux outils d'écriture.
3
Le schéma d'abord
Tables, colonnes, relations. Les outils d'interface n'apparaissent qu'une fois les données posées.
4
L'interface se construit sous tes yeux
Le code s'écrit dans l'éditeur et l'aperçu se rafraîchit. Ce qui ne va pas se corrige par retouches, pas par réécriture.
5
Tu publies
L'artefact est figé dans le document. Il n'a plus besoin du serveur, et l'utilisateur final ne voit qu'une application.

Cas d'usage

Quand ça compte

Un tableur qui a dépassé sa condition

Le fichier fait vivre un processus réel, mais chaque nouvelle demande se traduit par une colonne de plus et un onglet de plus.

Sans interface propre, on empile jusqu'à ce que plus personne n'ose y toucher.

Une équipe sans développeur disponible

Le besoin est clair et la file d'attente est longue. Ici, la personne qui connaît le métier construit et corrige elle-même.

Un outil livré six mois trop tard décrit un métier qui a changé entre-temps.

Des données qui ne doivent pas sortir

Serveur auto-hébergé, un déploiement par utilisateur, clés gardées côté serveur. Le document ne part pas chez un tiers pour être outillé.

Un service mutualisé demanderait de confier le document à quelqu'un d'autre.

Mise en ligne

En ligne, et tenu

Le serveur ne sert pas qu'en local. Déployé en ligne, il expose la même surface MCP, avec des gardes qui ne dépendent pas de la bonne volonté du client.

Une porte avant tout le reste

Un jeton d'application ferme /mcp, /register et le proxy sortant. La comparaison se fait en temps constant. Laissé vide en local, il n'y a pas de garde et rien ne change.

Le premier arrivé ferme la porte

Le premier compte Grist qui s'enregistre devient propriétaire du serveur ; tout autre compte est refusé. Une identité de repli, non résolue, n'épingle jamais rien — sinon elle verrouillerait le serveur sur personne.

Le serveur est son propre fournisseur d'identité

Un connecteur OAuth 2.1 complet : découverte, enregistrement dynamique du client, autorisation, jeton, PKCE S256. La clé Grist est donnée une fois au consentement et reste sur le serveur ; le client ne reçoit qu'un jeton opaque, expirable et révocable.

Les secrets ne sortent pas par les erreurs

La clé fuyait par l'URL d'appel dans les messages d'erreur. Tout ce qui remonte au client passe désormais par un masquage des jetons.

Le proxy sortant est fermé par défaut

L'appel au modèle n'accepte qu'une liste d'hôtes explicitement autorisés. Liste vide, l'endpoint est désactivé : pas de rebond possible vers un service interne.

La clé du modèle ne descend jamais au navigateur

Le widget demande au serveur ce qu'il sait du modèle et reçoit une base, un nom et un booléen — jamais la clé. Les sessions inactives sont purgées, et la diffusion temps réel est routée par utilisateur.

Journal

5.14

Corpus de savoir-faire interrogeable par l'assistant, sans exiger de session ouverte.

5.13

Connecteur OAuth 2.1 embarqué : le serveur devient son propre fournisseur d'identité, et le jeton émis est révocable.

5.12

Audit de sécurité : jetons masqués dans les erreurs, proxy sortant restreint à une liste d'hôtes, fuites mémoire fermées.

5.9

Publication autonome des artefacts, et aller-retour par le navigateur pour passer le pare-feu applicatif.