Donner à Claude (ou à n’importe quel agent) un outil de paperasse
La plupart des serveurs MCP donnent à un assistant un menu fixe d’outils: un par action, maintenu à la main, qui dérive hors sync avec la vraie API dès que quelque chose change. Le serveur MCP de CloudRaker fait autrement: il expose exactement deux outils, bâtis en direct à partir de la spécification OpenAPI de l’API elle-même, et laisse l’agent écrire et exécuter du vrai code contre toute la plateforme via ceux-ci. Pointez Claude, ChatGPT ou Codex dessus, et n’importe lequel peut chercher dans la surface API, générer un appel, puis parser, extraire, caviarder, remplir et signer un document, avec une étape d’approbation humaine qu’il attend plutôt que de dépasser à l’aveugle.
Deux outils, pas cinquante
Le serveur se place devant la passerelle CloudRaker et expose toute l’API via Code Mode, deux outils dérivés directement de la spécification OpenAPI en direct:
search— trouve les opérations pertinentes pour ce que l’agent essaie de faire.execute— exécute du TypeScript généré contre la passerelle pour le faire.
Parce que les deux outils sont bâtis à partir de la spécification en direct plutôt qu’écrits à la main par endpoint, le serveur MCP couvre toujours l’API complète automatiquement; il n’y a pas d’outil par endpoint qui puisse devenir obsolète. Quand CloudRaker livre une nouvelle capacité, elle apparaît ici sans que personne ne touche au serveur MCP lui-même.
Le code généré s’exécute dans un worker isolé sans réseau sortant propre. Le vrai appel à la passerelle se fait sur l’hôte, avec votre jeton bearer injecté là, pour que l’identifiant n’entre jamais dans le bac à sable d’exécution de code, et que le code généré n’ait aucun moyen de le voir ou de le fuiter.
Le brancher
Le serveur vit à https://mcp.cloudraker.com, et accepte deux types d’identifiants:
- Une clé API d’organisation, envoyée comme jeton Bearer — la même clé que vous utiliseriez avec les SDK. Le chemin le plus simple, ça marche partout.
- OAuth 2.0, pour les clients qui le supportent — découvert automatiquement, avec une connexion interactive et sans gestion manuelle de jeton. C’est ce que les connecteurs custom de claude.ai utilisent.
Pour Claude Code:
claude mcp add --transport http cloudraker https://mcp.cloudraker.com \
--header "Authorization: Bearer $CLOUDRAKER_API_KEY"
Ou dans .mcp.json:
{
"mcpServers": {
"cloudraker": {
"type": "http",
"url": "https://mcp.cloudraker.com",
"headers": { "Authorization": "Bearer <organization API key>" }
}
}
}
Pour claude.ai ou Claude Desktop, ajoutez un connecteur custom pointé vers https://mcp.cloudraker.com; il découvre le flux OAuth tout seul, sans jeton à copier nulle part.
Comme MCP est un standard ouvert, ChatGPT et Codex se branchent en principe de la même façon (même URL, même en-tête de jeton bearer), bien que les étapes exactes pour ajouter un connecteur MCP custom diffèrent selon le client — consultez la doc MCP de chaque plateforme pour le flux UI précis. Le chemin par en-tête de clé API reste un repli fiable partout où la découverte OAuth n’est pas supportée.
Il y a aussi un second serveur MCP, https://docs.cloudraker.com/_mcp/server, pour interroger directement la documentation CloudRaker au lieu de récupérer des pages. Job différent, même patron.
À quoi ça ressemble en pratique
Une fois branché, vous n’écrivez pas d’appels API; vous décrivez la tâche:
Voici un contrat fournisseur signé en PDF. Sors la durée du terme, les conditions de paiement et le délai de préavis de renouvellement, caviarde les renseignements personnels du signataire, et route-le pour validation conformité.
En coulisse, l’agent utilise search pour trouver les opérations pertinentes (extract, redact, et une exécution d’agent pour l’étape d’approbation), puis execute pour générer et lancer le code contre la passerelle: un appel d’extraction contre un schéma inféré ou fourni, une passe de caviardage, et une exécution d’agent qui s’arrête à un état needs_approval jusqu’à ce qu’une personne valide. Demandez des citations et vous obtenez des preuves page-et-région pour chaque champ, le même ancrage que vous auriez en appelant l’API directement.
Cette pause, c’est le point. Les exécutions d’agent CloudRaker sont une surface distincte des six verbes de base: un flux versionné, multi-étapes, qui inclut une porte de validation. Une exécution en file ou needs_approval ne continue pas toute seule; elle reste là jusqu’à ce qu’un humain la résolve. Un agent qui pilote ça via MCP hérite de la même discipline. Il peut mener un document presque jusqu’au bout, puis il s’arrête et attend, au lieu de sauter l’étape qu’un humain était censé vérifier.
Pourquoi la pause compte
La plupart des démos «l’IA fait la paperasse» s’arrêtent à l’extraction: le modèle lit un document et vous dit ce qu’il contient. Finir un document (rempli, approuvé, signé) passe encore habituellement par une personne à la main, parce que les outils qui pourraient l’automatiser n’exposent pas une étape d’approbation qu’un agent peut respecter.
C’est le fossé que le design à deux outils Code Mode et la porte d’approbation intégrée comblent tous les deux: non seulement laisser un agent lire un document, mais le laisser piloter tout le pipeline et savoir exactement où il doit s’arrêter.
Essayez-le
Branchez le serveur MCP de CloudRaker à Claude, ChatGPT ou Codex et donnez-lui un vrai document de votre flux: un contrat, une réclamation, un formulaire. Demandez-lui d’extraire, caviarder et router quelque chose pour approbation, et regardez-le vraiment attendre à l’étape de validation.