
mcp-remote exposé à une injection de commandes système
mcp-remoteConnectez un client MCP qui ne prend en charge que les serveurs locaux (stdio) à un serveur MCP distant, avec prise en charge de l'authentification :
Remarque : il s'agit d'une preuve de concept fonctionnelle mais doit être considérée comme expérimentale.
Jusqu'à présent, la majorité des serveurs MCP dans la nature sont installés localement, en utilisant le transport stdio. Cela présente certains avantages : le client et le serveur peuvent implicitement se faire confiance car l'utilisateur leur a accordé à tous deux l'autorisation de s'exécuter. L'ajout de secrets comme les clés API peut se faire via des variables d'environnement et ne quitte jamais votre machine. Et l'utilisation de npx et uvx a également permis aux utilisateurs d'éviter des étapes d'installation explicites.
Mais il y a une raison pour laquelle la plupart des logiciels qui pourraient être déplacés vers le web l'ont été : il est tellement plus facile de trouver et corriger des bugs et d'itérer sur de nouvelles fonctionnalités lorsque vous pouvez déployer des mises à jour à tous vos utilisateurs en un seul déploiement.
Avec la dernière spécification d'autorisation de MCP, nous avons désormais un moyen sécurisé de partager nos serveurs MCP avec le monde sans exécuter de code sur les ordinateurs portables des utilisateurs. Du moins, ce serait le cas, si tous les clients MCP populaires le prenaient déjà en charge. La plupart sont uniquement stdio, et ceux qui HTTP+SSE ne prennent pas encore en charge les flux OAuth requis.
C'est là que mcp-remote intervient. Dès que votre client MCP choisi prend en charge les serveurs distants et autorisés, vous pouvez le supprimer. En attendant, ajoutez cette ligne unique et habillez-vous pour les clients MCP que vous voulez !
Tous les clients MCP les plus populaires (Claude Desktop, Cursor et Windsurf) utilisent le format de configuration suivant :
{
"mcpServers": {
"remote-example": {
"command": "npx",
"args": [
"mcp-remote",
"https://remote.mcp.server/sse"
]
}
}
}
Pour contourner l'authentification, ou pour émettre des en-têtes personnalisés sur toutes les requêtes vers votre serveur distant, passez les arguments CLI --header :
{
"mcpServers": {
"remote-example": {
"command": "npx",
"args": [
"mcp-remote",
"https://remote.mcp.server/sse",
"--header",
"Authorization: Bearer ${AUTH_TOKEN}"
],
"env": {
"AUTH_TOKEN": "..."
}
},
}
}
Remarque : Cursor et Claude Desktop (Windows) ont un bogue où les espaces dans args ne sont pas échappés lors de l'appel à npx, ce qui finit par déformer ces valeurs. Vous pouvez contourner ce problème en utilisant :
{
// reste de la configuration...
"args": [
"mcp-remote",
"https://remote.mcp.server/sse",
"--header",
"Authorization:${AUTH_HEADER}" // notez l'absence d'espaces autour de ':'
],
"env": {
"AUTH_HEADER": "Bearer <auth-token>" // les espaces sont OK dans les variables d'environnement
}
},
npx produit des erreurs, pensez à ajouter -y comme premier argument pour accepter automatiquement l'installation du paquet mcp-remote. "command": "npx",
"args": [
"-y"
"mcp-remote",
"https://remote.mcp.server/sse"
]
npx à toujours vérifier une version mise à jour de mcp-remote, ajoutez le drapeau @latest : "args": [
"mcp-remote@latest",
"https://remote.mcp.server/sse"
]
mcp-remote écoute pour une redirection OAuth (par défaut 3334), ajoutez un argument supplémentaire après l'URL du serveur. Notez que quel que soit le port spécifié, s'il est indisponible, un port ouvert sera choisi aléatoirement. "args": [
"mcp-remote",
"https://remote.mcp.server/sse",
"9696"
]
mcp-remote enregistre comme URL de rappel OAuth (par défaut localhost), ajoutez le drapeau --host. "args": [
"mcp-remote",
"https://remote.mcp.server/sse",
"--host",
"127.0.0.1"
]
--allow-http. Remarque : Cela ne doit être utilisé que dans des réseaux privés sécurisés où le trafic ne peut pas être intercepté. "args": [
"mcp-remote",
"http://internal-service.vpc/sse",
"--allow-http"
]
--debug. Cela écrira des journaux verbeux dans ~/.mcp-auth/{server_hash}_debug.log avec des horodatages et des informations détaillées sur le processus d'authentification, les connexions et le rafraîchissement des jetons. "args": [
"mcp-remote",
"https://remote.mcp.server/sse",
"--debug"
]
--enable-proxy. Lorsqu'il est activé, mcp-remote utilisera les paramètres de proxy des variables d'environnement courantes (par exemple HTTP_PROXY, HTTPS_PROXY, et NO_PROXY). "args": [
"mcp-remote",
"https://remote.mcp.server/sse",
"--enable-proxy"
],
"env": {
"HTTPS_PROXY": "http://127.0.0.1:3128",
"NO_PROXY": "localhost,127.0.0.1"
}
--ignore-tool. Cela filtrera les outils correspondant aux motifs spécifiés des réponses tools/list et bloquera les requêtes tools/call. Prend en charge les motifs génériques avec *. "args": [
"mcp-remote",
"https://remote.mcp.server/sse",
"--ignore-tool",
"delete*",
"--ignore-tool",
"remove*"
]
Vous pouvez spécifier plusieurs drapeaux --ignore-tool pour ignorer différents motifs. Exemples :
delete* - ignore tous les outils commençant par "delete" (par exemple, deleteTask, deleteUser)*account - ignore tous les outils se terminant par "account" (par exemple, getAccount, updateAccount)exactTool - ignore uniquement l'outil nommé exactement "exactTool"30 secondes), ajoutez le drapeau --auth-timeout avec une valeur en secondes. Cela est utile si le processus d'authentification côté serveur prend beaucoup de temps. "args": [
"mcp-remote",
"https://remote.mcp.server/sse",
"--auth-timeout",
"60"
]
MCP Remote prend en charge différentes stratégies de transport lors de la connexion à un serveur MCP. Cela vous permet de contrôler s'il utilise le transport SSE (Server-Sent Events) ou HTTP, et dans quel ordre il les essaie.
Spécifiez la stratégie de transport avec le drapeau --transport :
npx mcp-remote https://example.remote/server --transport sse-only
Stratégies disponibles :
http-first (par défaut) : Essaie d'abord le transport HTTP, puis bascule vers SSE si HTTP échoue avec une erreur 404sse-first : Essaie d'abord le transport SSE, puis bascule vers HTTP si SSE échoue avec une erreur 405http-only : Utilise uniquement le transport HTTP, échoue si le serveur ne le prend pas en chargesse-only : Utilise uniquement le transport SSE, échoue si le serveur ne le prend pas en chargeMCP Remote prend en charge la fourniture de métadonnées statiques du client OAuth au lieu d'utiliser les valeurs par défaut de mcp-remote. Cela est utile lors de la connexion à des serveurs OAuth qui attendent des identifiants de client/logiciel ou des portées spécifiques.
Fournissez les métadonnées du client sous forme de chaîne JSON ou de chemin de fichier préfixé par @ avec le drapeau --static-oauth-client-metadata :
npx mcp-remote https://example.remote/server --static-oauth-client-metadata '{ "scope": "space separated scopes" }'
# utilise node readfile, donc vous voudrez probablement utiliser des chemins absolus si vous n'êtes pas sûr du répertoire de travail courant
npx mcp-remote https://example.remote/server --static-oauth-client-metadata '@/Users/username/Library/Application Support/Claude/oauth_client_metadata.json'
Conformément à la spécification, les serveurs sont encouragés mais non obligés à prendre en charge l'enregistrement dynamique du client OAuth.
Pour ces serveurs, MCP Remote prend en charge la fourniture d'informations statiques du client OAuth à la place. Cela est utile lors de la connexion à des serveurs OAuth qui nécessitent des clients pré-enregistrés.
Fournissez les métadonnées du client sous forme de chaîne JSON ou de chemin de fichier préfixé par @ avec le drapeau --static-oauth-client-info :
export MCP_REMOTE_CLIENT_ID=xxx
export MCP_REMOTE_CLIENT_SECRET=yyy
npx mcp-remote https://example.remote/server --static-oauth-client-info "{ \"client_id\": \"$MCP_REMOTE_CLIENT_ID\", \"client_secret\": \"$MCP_REMOTE_CLIENT_SECRET\" }"
# utilise node readfile, donc vous voudrez probablement utiliser des chemins absolus si vous n'êtes pas sûr du répertoire de travail courant
npx mcp-remote https://example.remote/server --static-oauth-client-info '@/Users/username/Library/Application Support/Claude/oauth_client_info.json'
Pour ajouter un serveur MCP à Claude Desktop, vous devez modifier le fichier de configuration situé à :
~/Library/Application Support/Claude/claude_desktop_config.json%APPDATA%\Claude\claude_desktop_config.jsonS'il n'existe pas encore, vous devrez peut-être l'activer sous Paramètres > Développeur.
Redémarrez Claude Desktop pour prendre en compte les modifications du fichier de configuration. Après le redémarrage, vous devriez voir une icône de marteau dans le coin inférieur droit de la zone de saisie.
Documentation officielle. Le fichier de configuration se trouve à ~/.cursor/mcp.json.
Depuis la version 0.48.0, Cursor prend en charge les serveurs SSE non authentifiés directement. Si votre serveur MCP utilise le protocole d'autorisation OAuth officiel de MCP, vous devez toujours ajouter un serveur de type "command" et appeler mcp-remote.
Documentation officielle. Le fichier de configuration se trouve à ~/.codeium/windsurf/mcp_config.json.
Pour des instructions sur la construction et le déploiement de serveurs MCP distants, y compris le fait d'agir en tant que client OAuth valide, consultez les ressources suivantes :
En particulier, voir :
McpAgent utilisant le framework agents.Pour plus d'informations sur le test de ces serveurs, voir également :
Vous connaissez d'autres ressources que vous aimeriez partager ? Veuillez les ajouter à ce Readme et envoyer une PR !
~/.mcp-authmcp-remote stocke toutes les informations d'identification dans ~/.mcp-auth (ou là où pointe votre variable MCP_REMOTE_CONFIG_DIR). Si vous rencontrez des problèmes persistants, essayez d'exécuter :
rm -rf ~/.mcp-auth
Puis redémarrez votre client MCP.
Assurez-vous que la version de Node que vous avez installée est 18 ou supérieure. Claude Desktop utilisera la version système de Node, même si vous avez une version plus récente installée ailleurs.
Lors de la modification de claude_desktop_config.json, il peut être utile de redémarrer complètement Claude
Vous pouvez rencontrer des problèmes si vous êtes derrière un VPN ; vous pouvez essayer de définir la variable d'environnement NODE_EXTRA_CA_CERTS
pour pointer vers le fichier de certificat CA. Si vous utilisez claude_desktop_config.json,
cela pourrait ressembler à :
{
"mcpServers": {
"remote-example": {
"command": "npx",
"args": [
"mcp-remote",
"https://remote.mcp.server/sse"
],
"env": {
"NODE_EXTRA_CA_CERTS": "{chemin de votre fichier de certificat CA}.pem"
}
}
}
}
tail -n 20 -F ~/Library/Logs/Claude/mcp*.logtail -n 20 -f "C:\Users\VotreNomUtilisateur\AppData\Local\Claude\Logs\mcp.log"Get-Content "C:\Users\VotreNomUtilisateur\AppData\Local\Claude\Logs\mcp.log" -Wait -Tail 20Pour résoudre des problèmes complexes, en particulier ceux liés au rafraîchissement des jetons ou à l'authentification, utilisez le drapeau --debug :
"args": [
"mcp-remote",
"https://remote.mcp.server/sse",
"--debug"
]
Cela crée des journaux détaillés dans ~/.mcp-auth/{server_hash}_debug.log avec des horodatages et des informations complètes sur chaque étape du processus de connexion et d'authentification. Lorsque vous rencontrez des problèmes de rafraîchissement de jetons, de mise en veille/réveil de l'ordinateur portable ou d'authentification, fournissez ces journaux lorsque vous demandez de l'aide.
Si vous rencontrez l'erreur suivante, renvoyée par l'URL /callback :
Erreur d'authentification
L'échange de jeton a échoué : HTTP 400
Vous pouvez exécuter rm -rf ~/.mcp-auth pour effacer tout état et jeton stockés localement.
Exécutez la commande suivante sur la ligne de commande (pas à partir d'un serveur MCP) :
npx -p mcp-remote@latest mcp-remote-client https://remote.mcp.server/sse
Cela parcourra tout le flux d'autorisation et tentera de lister les outils et ressources à l'URL distante. Essayez cela après avoir exécuté rm -rf ~/.mcp-auth pour voir si des identifiants obsolètes sont votre problème ; sinon, espérons que le problème sera plus évident dans ces journaux que dans ceux de votre client MCP.