MCP in Worker

MCP in Worker donne aux assistants IA des outils directs vers vos données sans infrastructure MCP séparée. Un unique endpoint POST /mcp dans votre Cloudflare Worker existant parle MCP en HTTP streamable (JSON-RPC 2.0) et réutilise vos handlers API testés. Éprouvé en production avec trois outils, bilingue, sans authentification : recherche, détail d'une fiche, et payload d'action. Le pattern est volontairement compact. Vous définissez trois à cinq outils en lecture seule avec des schémas JSON stricts : la recherche prend les mots de l'utilisateur tels quels sans les traduire (plafonnés à ~120 caractères), le détail renvoie la fiche complète, et l'outil d'action renvoie un payload à copier-coller que l'utilisateur confirme ailleurs. Au lieu de réimplémenter la recherche, vous synthétisez une Request interne vers votre propre endpoint testé en transférant les headers de l'appelant, pour que les rate limits par IP, le ranking, les synonymes et la journalisation se comportent à l'identique. Le point d'entrée du worker câble trois routes avant tout autre handler : POST /mcp est le dispatcher JSON-RPC (initialize, tools/list, tools/call, ping), GET /mcp renvoie une page d'info lisible décrivant l'endpoint et ses outils, et OPTIONS /mcp répond au preflight CORS car les clients MCP sont cross-origin. Les résultats d'outils sont du texte brut ou du contenu structuré que le modèle peut citer, jamais du HTML. Les règles d'exploitation le gardent sûr : lecture seule, aucun outil n'écrit, ne supprime ni ne dépense. Les descriptions d'outils sont autonomes car le modèle appelant ne voit jamais votre site, seulement ces chaînes. Le CORS autorise Content-Type, Accept et Mcp-Session-Id. L'endpoint est public par design, donc il ne journalise ni ne renvoie jamais de secrets, et il a son propre rate limit comme l'API sous-jacente car les clients MCP réessaient agressivement. Si votre pipeline de déploiement neutralise des routes, exemptez /mcp explicitement et revérifiez après chaque déploiement.