BlogData RoomsLe serveur MCP Papermark : le premier MCP de data room pour Claude et ChatGPT

Le serveur MCP Papermark : le premier MCP de data room pour Claude et ChatGPT

16 min de lecture
Marc Seitz

Marc Seitz

Papermark propose désormais un serveur MCP officiel : @papermark/mcp-server sur npm, exposant 43 outils typés qui encapsulent l'intégralité de l'API Papermark pour les data rooms, les documents, les liens, les dossiers, les visiteurs et les analyses. Connectez-le à Claude Desktop avec un simple extrait JSON, et un agent IA peut créer une data room, importer des documents en masse, générer des liens personnalisés par investisseur et consulter les analyses de consultation page par page en votre nom. À notre connaissance, Papermark est le premier fournisseur de data room virtuelle doté d'un véritable serveur MCP, tandis que les VDR historiques comme Intralinks, Datasite et DocSend ne proposent aucune intégration MCP et, dans le cas de DocSend, aucune API publique.

Qu'est-ce qu'un serveur MCP de data room ?

MCP (Model Context Protocol) est le standard ouvert qui permet à un agent IA de découvrir et d'appeler des outils fonctionnant en dehors de son propre environnement isolé. Un serveur MCP de data room prend les opérations que vous effectueriez normalement dans un tableau de bord VDR (créer une salle, importer des fichiers, configurer un lien de partage, vérifier qui a consulté quoi) et les expose sous forme d'outils qu'un agent comme Claude peut appeler directement.

Le serveur MCP Papermark reproduit l'API REST Papermark de manière exacte et exhaustive. Les arguments des outils utilisent les mêmes structures que les corps de requêtes de l'API, les résultats reflètent les réponses de l'API champ par champ, et rien n'est simulé ou factice. Si l'API peut le faire, l'agent peut le faire, ce qui couvre les six ressources constituant un compte Papermark : les data rooms, les documents, les dossiers, les liens, les visiteurs et les analyses.

Il est disponible en deux transports. Le transport stdio (@papermark/mcp-server sur npm) s'exécute en local et est le meilleur choix pour Claude Desktop et Claude Code, avec l'avantage que l'agent peut télécharger des fichiers directement depuis votre disque. Le transport HTTP est hébergé à mcp.papermark.com/mcp pour les clients basés sur navigateur comme les Connecteurs claude.ai et les Applications ChatGPT, avec une authentification via OAuth. Les mêmes outils, les mêmes structures, sur les deux.

Les 43 outils MCP, regroupés par ressource

Lorsque Claude se connecte au serveur MCP de Papermark, il ne voit pas 43 fonctions indifférenciées. Il voit un catalogue typé organisé autour des six mêmes ressources que l'API data room de Papermark : data rooms, documents, dossiers, liens, visiteurs et analytiques. Chaque outil porte un nom, une description et un schéma JSON pour ses arguments, et le modèle lit ce catalogue comme vous parcourriez un menu, en sélectionnant l'outil dont le schéma correspond à votre demande. Étant donné que les schémas sont générés à partir de la spécification OpenAPI de l'API, l'agent ne tente jamais de deviner la structure des arguments comme il le ferait s'il écrivait des requêtes HTTP brutes à la main.

Le regroupement est important car il reflète la façon dont vous parlez réellement à l'agent. Posez une question sur la configuration et le modèle se tourne vers les outils de data room et de documents ; posez une question sur les accès et il se tourne vers les liens ; demandez « qui a lu ceci » et il se tourne vers les visiteurs et les analytiques. Vous n'avez jamais à nommer un outil vous-même. Vous décrivez le résultat en langage naturel, et la couche Model Context Protocol transforme cette phrase en la bonne séquence d'appels d'outils MCP, chacun accédant à votre compte Papermark via votre token. Le tableau ci-dessous représente le modèle mental à retenir : ce que fait chaque catégorie d'outils, une invite qui la déclenche, et ce qu'elle renvoie.

La répartition indique également où se situe le risque. Les catégories de lecture (analytique, visiteurs, la plupart des documents et des data rooms) peuvent être confiées en toute sécurité à un agent en fonctionnement permanent. Les catégories d'écriture (création de liens, téléversement de documents) sont celles pour lesquelles vous définissez délibérément la portée, et les actions destructrices au sein de chaque catégorie — suppression d'une room, d'un document ou d'un lien — sont celles que vous excluez entièrement de la portée par défaut d'un agent, un point sur lequel la section sécurité reviendra.

Catégorie d'outilExemple de promptCe que fait l'agent
Data rooms"Créer une data room appelée Acme Series B"Appelle create_dataroom, retourne le nouveau dataroom_id sur lequel repose le reste du workflow
Documents"Téléverser tous les PDF dans ~/acme/ et placer les documents financiers dans un dossier Financials"Enchaîne upload_document par fichier ainsi que les outils de dossiers, en comparant avec ce qui existe déjà
Liens"Créer un lien protégé par mot de passe pour Sequoia qui expire le 30 septembre"Appelle create_link avec le dataroom_id, le mot de passe, la date d'expiration et la vérification par e-mail en tant que champs
Analytique"Qui chez Acme a passé le plus de temps sur le mémo investisseur ?"Enchaîne get_document_analytics, list_link_views et get_view_analytics pour les durées par page
Visiteurs"Lister toutes les personnes qui ont ouvert la room Series B et à quel moment"Parcourt list_visitors et l'historique de consultation de chaque visiteur, retourné sous forme de texte lisible

Les outils de lecture concentrent l'essentiel de la valeur au quotidien, car une VDR n'est utile qu'à hauteur des informations qu'elle vous renvoie. Les outils d'écriture sont ceux qui remplacent les clics dans le tableau de bord. Quant aux outils destructeurs, ils existent mais sont délibérément difficiles d'accès — c'est précisément l'intérêt du modèle de portée.

Configuration de Claude Desktop en 30 secondes

Connecter le serveur MCP Papermark à Claude Desktop ne nécessite qu'une simple modification de configuration, pas un processus d'installation. Pas de SDK à importer, pas de serveur local à maintenir en fonctionnement, et pas d'authentification OAuth pour le transport stdio — vous collez un token, redémarrez l'application, et Claude peut piloter votre VDR. L'opération est volontairement plus rapide que la lecture de la documentation correspondante, et c'est le moyen le plus rapide de voir un agent IA créer et gérer une vraie data room.

Générez un token API dans le tableau de bord Papermark, sous Paramètres, puis Tokens API. Définissez les permissions selon ce que cet agent doit pouvoir faire (commencez en lecture seule si vous testez simplement), puis ajoutez ceci à ~/Library/Application Support/Claude/claude_desktop_config.json :

{
"mcpServers": {
"papermark": {
"command": "npx",
"args": ["-y", "@papermark/mcp-server"],
"env": {
"PAPERMARK_TOKEN": "pm_live_your_token_here"
}
}
}
}

Redémarrez Claude Desktop. C'est tout pour la configuration : aucune étape d'installation, car npx télécharge le package depuis npm au premier lancement (environ 5 secondes, une seule fois). Vous avez besoin de Node 24+ sur votre machine. Vérifiez en demandant à Claude de « lister mes documents Papermark », et en cas de problème, la documentation Claude Desktop associe chaque message de log à sa solution.

Partagez des documents de façon moderne

Aucune carte de crédit requise

Analyses page par page
Vérification d'email requise
Mot de passe requis pour visualiser
Autoriser/Bloquer des utilisateurs spécifiques
Appliquer un filigrane
Exiger un NDA pour visualiser
Message d'accueil personnalisé

5 prompts concrets à utiliser dès aujourd'hui

L'intérêt d'un serveur MCP pour data room, c'est que vous arrêtez de traduire vos intentions en clics. Vous exprimez ce que vous voulez en une phrase, et Claude détermine lequel des 43 outils MCP appeler et dans quel ordre. Les prompts ci-dessous sont ceux qui méritent d'être mémorisés, car ils couvrent l'ensemble du cycle de vie d'une data room virtuelle : la créer, la remplir, la partager par investisseur, la mesurer et l'auditer. Chacun correspond à un vrai processus qu'un fondateur exécute lors d'une levée de fonds, pas à une simple démonstration.

Ce sont des invites testées, pas des démos aspirationnelles. Chacune correspond à une chaîne d'appels d'outils MCP que l'agent sélectionne de lui-même. Lisez-les comme des modèles plutôt que comme des formules magiques — l'agent gère très bien les paraphrases, donc « créer une salle et charger ces fichiers » aboutit aux mêmes outils que la formulation exacte ici. Ce qui reste constant, c'est la structure : décrivez le résultat souhaité, précisez les contraintes (mot de passe, expiration, vérification par e-mail), et laissez la couche Model Context Protocol s'occuper du reste.

1. Créer une data room from scratch

« Crée une data room appelée 'Acme Series B', télécharge tous les PDF dans ~/acme/ et génère un lien unique protégé par mot de passe. »

L'agent appelle create_dataroom, puis upload_document par fichier, puis create_link avec le dataroom_id et un mot de passe. Une seule phrase remplace environ vingt minutes de clics dans le tableau de bord. Le guide complet est disponible dans comment créer une data room avec Claude.

2. Téléchargement en masse et organisation

« Synchronise tous les PDF dans ~/Drive/Acme/ dans la data room 'Acme current'. Crée-la si elle n'existe pas, ignore les fichiers déjà présents, et place les états financiers dans un dossier Financials. »

L'agent vérifie list_datarooms, crée la salle si nécessaire, compare avec list_dataroom_documents, et télécharge uniquement ce qui manque. L'invite est idempotente, vous pouvez donc la relancer chaque semaine au fur et à mesure que de nouveaux documents arrivent.

3. Liens par investisseur

« Crée un lien distinct vers la data room Acme Series B pour chacune de ces sociétés : Sequoia, Index, Point Nine. Vérification par e-mail activée, téléchargements désactivés, expiration le 30 septembre. »

Un appel create_link par société, tous pointant vers le même dataroom_id. Comme les analytiques sont par lien, vous savez quelle société lit réellement le document et quel associé l'a transmis en interne. C'est le flux de travail décrit dans pourquoi les startups suivent l'engagement des investisseurs.

4. Analyses sans tableau de bord

"Comment se comporte le mémo destiné aux investisseurs ? Montre-moi les statistiques globales, puis dis-moi qui chez Acme a passé le plus de temps dessus, et sur quelles pages ils se sont attardés."

L'agent enchaîne get_document_analytics, list_links, list_link_views et get_view_analytics pour les durées page par page, puis filtre par domaine e-mail et trie par temps passé. Vous obtenez une réponse en texte continu plutôt qu'un export de tableau de bord.

5. Audit trimestriel

"Effectue un audit de mon compte Papermark. Liste toutes les data rooms, les documents qu'elles contiennent, les liens existants, et signale tout lien sans mot de passe ni date d'expiration."

L'agent parcourt list_datarooms, list_dataroom_documents et list_links, puis signale les liens ouverts qui devraient être sécurisés. Exécutez-le une fois par trimestre comme vérification de routine. Retrouvez d'autres modèles similaires dans le guide des workflows d'agents.

Une levée de fonds d'amorçage, gérée de bout en bout avec Claude

Imaginez une fondatrice technique solo lançant un tour d'amorçage un mardi soir, son pitch deck et ses données financières dans un dossier local, sans aucune envie d'apprendre à utiliser un tableau de bord VDR. Elle ouvre Claude Desktop avec le serveur MCP Papermark connecté via un token d'écriture limité et saisit une seule phrase : « Crée une data room appelée 'Nimbus Seed', télécharge tous les PDF présents dans ~/nimbus/raise/, et organise le modèle financier et le tableau de capitalisation dans un dossier Financials. » Claude appelle create_dataroom, fait tourner upload_document sur le dossier, crée le dossier et confirme la room en une vingtaine de secondes. Elle ne voit jamais un seul écran de paramètres.

Elle décrit ensuite la prospection : « Crée un lien distinct avec accès par e-mail pour chaque cabinet listé dans investors.txt, téléchargements désactivés, expiration dans six semaines. » Un create_link par cabinet, tous pointant vers la même room, chacun avec sa propre piste d'analyse. Elle colle les URLs dans ses e-mails d'introduction et envoie le tout avant d'aller se coucher.

Le jeudi, la levée de fonds est devenue un jeu d'information, et elle l'aborde à partir d'une invite : « Qui s'intéresse vraiment à la salle Nimbus ? » Claude enchaîne les outils d'analyse et répond en prose — un fonds a passé onze minutes sur le modèle et est revenu deux fois, un autre n'a ouvert la diapositive de couverture qu'une seule fois. Elle concentre ses relances sur la société que les données indiquent comme étant la plus intéressée. Lorsqu'un associé demande des chiffres mis à jour, elle publie une nouvelle version du document et tous les liens existants servent la version actualisée. Quand elle souhaite supprimer une salle, elle le fait elle-même depuis le tableau de bord, sans passer par l'agent.

Salle de données gérée via le serveur Papermark MCP

Une salle de données Papermark comme celle qu'un agent IA provisionne, remplit et partage via le serveur MCP — pendant que vous conservez les actions destructrices dans le tableau de bord.

Le modèle de sécurité : des périmètres, pas de la confiance

Confier à un agent IA un accès en écriture à vos documents de due diligence est une chose qui mérite d'être abordée avec prudence, c'est pourquoi le modèle de permissions est délibérément simple : l'agent agit en votre nom, via votre token API, et les périmètres du token sont appliqués côté serveur à chaque appel. Il n'existe pas d'« identité MCP » distincte ni de canal secondaire.

Cela vous donne trois contrôles concrets. Premièrement, un token en lecture seule (documents.read, links.read, analytics.read) produit un agent en lecture seule : chaque outil d'écriture renvoie 403 forbidden et l'agent l'indique clairement. Deuxièmement, les périmètres sont granulaires par ressource, ce qui vous permet d'autoriser la création de liens sans autoriser la suppression de documents. Troisièmement, les tokens sont révocables à tout moment depuis le tableau de bord.

Nos paramètres par défaut recommandés : attribuez un jeton en lecture seule à un assistant à longue durée de vie, créez des jetons d'écriture à portée limitée pour chaque tâche et révoquez-les ensuite, et ne demandez jamais à un agent de supprimer des éléments en masse. Les suppressions sont soumises à des portées comme tout le reste, mais les erreurs sont irrécupérables — gardez donc les opérations destructives dans le tableau de bord ou dans le CLI où vous pouvez voir exactement ce que vous faites.

Faites-en une règle permanente : les opérations destructives restent en dehors de la portée par défaut de l'agent et nécessitent une intervention humaine. Le serveur MCP expose bien des outils de suppression — delete_dataroom, delete_document, delete_link — car l'API le fait, et refuser de les intégrer serait simplement malhonnête quant à la nature de la surface. Mais il existe une frontière nette entre un agent qui peut consulter vos analyses toute la journée et un agent qui peut supprimer une salle : le modèle de portée trace cette ligne délibérément. Un jeton de lecture ou d'écriture ne peut toujours pas supprimer ; un jeton capable de suppression est celui que vous créez sciemment, utilisez pour une opération spécifique, puis révoquez. Lorsqu'une salle doit réellement être supprimée, vous l'approuvez vous-même dans le tableau de bord, de la même façon que vous garderiez la boucle de révocation hors de portée des agents IA dans un script. Rien dans ce flux de travail ne vous demande de faire confiance au modèle pour une action irréversible.

En résumé, un agent IA qui opère sur votre VDR ne fonctionne jamais sur la confiance — il opère sur des identifiants dont vous avez choisi le rayon d'action exact. C'est ce qui fait que confier votre data room à Claude est une décision raisonnable plutôt qu'un acte de foi : le pire qu'un agent en lecture seule puisse faire, c'est vous dire quelque chose que vous ne vouliez pas entendre, et le pire qu'un agent d'écriture à portée limitée puisse faire, c'est créer un lien que vous pouvez révoquer en un clic.

Pourquoi le secteur des VDR n'a pas encore d'histoire MCP

Les salles de données virtuelles font partie des catégories de logiciels les moins accessibles aux développeurs. Datasite et Intralinks proposent des contrats entreprise à partir de 25 000 $/an, avec des intégrations livrées via des équipes d'ingénierie commerciale, et non via une documentation en libre-service. DocSend, bien qu'appartenant à Dropbox, ne dispose ni d'API publique ni de portail développeur, ce qui rend structurellement impossible la mise en place d'un serveur MCP aujourd'hui. Résultat : en 2026, aucun fournisseur VDR historique n'offre à un agent IA un moyen officiel d'opérer une salle de données.

Papermark part dans la direction opposée. L'API compte 43 opérations avec une spécification OpenAPI, et le serveur MCP en est une interface légère et transparente. La tarification du plan Data Rooms est claire : 99 €/mois avec 7 jours d'essai gratuit, et la surface développeur (API, CLI, MCP) est disponible à partir des plans Business. Si vous comparez les fournisseurs sur ce critère, le panorama des meilleures salles de données virtuelles indique où se situe chaque éditeur.

Serveur MCP, API REST ou CLI : quelle porte emprunter

Le serveur MCP de Papermark est l'une des trois façons d'accéder à la même salle de données. Comme ils partagent un token et un modèle de données, rien de ce que vous construisez sur l'un n'est perdu lorsque vous passez à un autre. Une salle créée par Claude via le serveur MCP est identique, octet pour octet, à celle que crée l'API REST ou la CLI. La question n'est jamais de savoir quelle interface est la meilleure dans l'absolu, mais laquelle correspond à la tâche en cours — et faire le bon choix dès le départ vous évite de devoir porter un workflow plus tard.

Privilégiez le serveur MCP lorsque le travail est conversationnel et variable — vous préférez décrire le résultat à Claude ou ChatGPT plutôt que d'écrire les étapes, et vous valorisez la flexibilité plutôt que la reproductibilité octet par octet. C'est l'outil idéal pour l'analyse exploratoire ("qui est engagé ?"), la configuration ponctuelle d'espaces, et tout flux de travail dont la séquence exacte change d'une exécution à l'autre. Privilégiez l'API REST lorsque vous créez un service backend qui génère des liens selon un calendrier ou en réponse aux événements de votre propre application, lorsque vous souhaitez des réponses typées et un contrôle explicite des nouvelles tentatives. Et privilégiez la CLI lorsque le travail est un script déterministe, une tâche cron ou une étape CI que vous souhaitez reproductible à l'octet près — la structure dossier en entrée, liste de liens en sortie sur laquelle le guide CLI pour la collecte de fonds est fondé.

En pratique, la plupart des fondateurs utilisent les trois : le serveur MCP pour la lecture conversationnelle quotidienne, la CLI pour le script de configuration répétable, et l'API REST uniquement lorsqu'un flux de travail doit s'exécuter au sein d'un service. Comme un seul token couvre les trois, vous pouvez commencer par demander à Claude et faire évoluer un chemin critique vers du code dès qu'il doit être reproductible, sans aucun coût de migration.

Pour commencer

Le chemin le plus rapide est la configuration Claude Desktop en 30 secondes décrite ci-dessus, puis l'invite n°1. Si vous préférez scripter plutôt que discuter, la même surface d'API est disponible via la CLI Papermark et l'API REST. Et si vous souhaitez voir jusqu'où vont les flux de travail agentiques, nous avons créé un agent de due diligence complet avec Claude et Papermark comme exemple concret.

Présentation du serveur MCP Papermark

FAQ

More useful articles from Papermark

Prêt à créer votre data room sécurisée ?