IA 101 - Épisode 5. Ajouter MCP à ColdFusion AI : donner un passeport au robot

Dans les derniers articles, nous avons progressivement bâti un assistant IA ColdFusion sans lui donner assez de corde pour faire de la descente en rappel jusqu’en production et commencer à prendre des décisions architecturales.

Nous avons commencé par le vocabulaire : LLM, prompts, jetons, fenêtres de contexte, température, hallucinations, mémoire, outils, RAG, MCP et garde-fous.

Ensuite, nous avons construit la version ColdFusion IA de « Hello World » avec ChatModel(). Envoyez un prompt. Obtenez une réponse. Affichez response.message. Simple et efficace.

Après cela, nous avons introduit Agent() et la mémoire. L’assistant pouvait enfin se souvenir de ce que l’utilisateur venait de dire, conserver le contexte de la conversation à court terme et cesser d’agir comme si chaque requête lui était criée dessus depuis un stationnement différent.

Nous avons ensuite ajouté des outils CFC. C’était une amélioration majeure. Au lieu de deviner le statut d’un billet, d’une commande, d’une inscription ou d’autres faits propres à l’application, l’assistant pouvait demander un accès contrôlé aux méthodes ColdFusion. L’IA pouvait demander. ColdFusion pouvait valider, autoriser, exécuter et décider.

Nous en sommes arrivés à ce point :

ChatModel() : Bien pour les prompts simples et sans état.
Agent() avec mémoire : Bien pour les conversations à plusieurs tours et le contexte par utilisateur.
Agent() avec outils CFC : Bien pour permettre à l’IA de demander des capacités dans votre application ColdFusion.

Passons maintenant à la couche suivante :

Agent() avec MCP : Bien pour connecter les flux de travail IA à des outils, des prompts et des ressources via un protocole standard.

Cet article porte sur l’ajout de MCP. Et oui, c’est un autre acronyme. Désolé. À ce stade, le développement IA a assez d’acronymes pour se qualifier comme ministère.

Quel problème MCP résout-il ?

Les outils CFC sont excellents lorsque ce que vous voulez que l’IA utilise se trouve dans votre application ColdFusion. Par exemple :

getTicketStatus( ticketId );
calculateCartTotal( cartId );
listUpcomingEvents( userId );
createSupportTicket( summary, priority );

Ce sont des capacités locales de l’application. Vous détenez le code. Vous pouvez exposer des méthodes CFC précises à l’agent. Vous pouvez valider les arguments et faire respecter l’autorisation à l’intérieur de l’outil. C’est une bonne approche. Mais que se passe-t-il lorsque ce dont l’IA a besoin n’est pas local ? Et si l’assistant doit communiquer avec :

• Jira
• Confluence
• GitHub
• Slack
• un wiki interne
• un service de rapports
• un système de documents
• une autre application ColdFusion
• un serveur d’outils d’entreprise partagé
• un service appartenant à une autre équipe qui a déjà des opinions bien arrêtées et trois diagrammes d’architecture

Vous pourriez écrire des intégrations ponctuelles pour chaque système. Vous pourriez créer des enveloppes personnalisées. Vous pourriez inventer votre propre format de découverte d’outils. Vous pourriez envoyer un courriel à une autre équipe pour leur demander la documentation, puis attendre six mois et recevoir un PDF mis à jour pour la dernière fois à l’époque de jQuery.

Ou vous pourriez utiliser un protocole standard. C’est là que MCP entre en jeu.

MCP, ou Model Context Protocol, donne aux clients IA et aux systèmes externes une façon cohérente de communiquer. Adobe décrit MCP comme le protocole que les agents IA utilisent pour communiquer avec des systèmes externes de manière cohérente et vérifiable. Il standardise la découverte et l’appel d’outils, la gestion des prompts, l’accès aux ressources et des flux facultatifs tels que l’échantillonnage, l’élicitation, la journalisation et les racines. (guides.adobe.com)

En anglais simple : « MCP est une façon standard pour les applications IA de découvrir et d’utiliser des outils, des prompts et des ressources en dehors de l’application immédiate. »

Ou, encore plus simplement : « Les outils CFC permettent au robot d’utiliser votre application. MCP permet au robot d’utiliser d’autres systèmes sans que chaque intégration devienne une snowflake sur mesure. »

Un modèle mental rapide

Pensez à MCP comme à un contrat entre deux côtés. D’un côté, vous avez un hôte ou client IA. De l’autre côté, vous avez un serveur MCP. Le client demande :

What tools do you have?

Le serveur répond :

I have these tools:
- getTicketStatus
- searchDocs
- createIssue

Le client demande :

Can you call searchDocs with this query?

Le serveur répond :

Here are the results.

C’est l’idée de base. MCP standardise cette conversation. Le client n’a pas besoin de connaître les détails d’implémentation du serveur. Il n’a pas besoin de savoir si le serveur est écrit en ColdFusion, Node, Python, Java, Go ou dans n’importe quel autre langage qu’une personne a choisi après avoir dit : « Ce ne sera qu’un petit service. » Il a seulement besoin de parler MCP.

Les trois rôles : hôte, client et serveur

La documentation d’Adobe décrit trois rôles MCP principaux : hôte, client et serveur. ColdFusion peut participer à plus d’un rôle. (guides.adobe.com) Traduisons cela en termes de développeur.

Hôte MCP

L’hôte est l’application externe qui gère l’expérience utilisateur.

Il possède généralement :

• l’interface utilisateur
• la conversation
• l’interaction avec le LLM
• les sessions utilisateur
• le moment d’appeler les outils
• ce qu’il faut montrer à l’utilisateur

Des exemples d’hôtes comprennent des applications comme Claude Desktop, Cursor ou une application web ColdFusion qui maintient les sessions utilisateur et appelle les outils MCP au besoin.

Dans notre série, votre application ColdFusion peut être l’hôte. Elle a la page, la session, l’identifiant de l’utilisateur, l’état d’authentification, le déroulement de la conversation et la responsabilité profondément injuste de faire en sorte que tout paraisse facile.

Client MCP

Le client MCP est l’adaptateur de protocole. Il sait comment communiquer avec des serveurs MCP au moyen de transports pris en charge comme HTTP ou STDIO. La documentation d’Adobe décrit MCPClient(configData) comme la principale façon de créer des clients MCP dans ColdFusion. Le client MCP expose des méthodes adaptées à ColdFusion comme listTools(), callTool(), listResources(), readResource(), listPrompts() et getPrompt(). (guides.adobe.com)

En français simple : le client MCP est la façon dont votre application ColdFusion communique avec un serveur MCP. Il effectue la négociation initiale, gère les détails du protocole et donne à votre code CFML des méthodes qui ressemblent à des appels d’application normaux plutôt qu’à des contorsions autour d’un protocole brut. C’est bien, parce que la plupart d’entre nous avons déjà assez de JSON-RPC dans notre vie.

Serveur MCP

Le serveur MCP fournit des capacités. Il peut exposer :

• des outils
• des invites
• des ressources

La documentation d’Adobe décrit le serveur MCP comme le fournisseur de capacités. Il peut encapsuler des API externes, des systèmes de fichiers ou des CFC ColdFusion, et il reçoit des méthodes MCP standardisées comme tools/list, tools/call et prompts/get. ColdFusion crée des serveurs MCP au moyen de MCPServer(configData). (guides.adobe.com)

En français simple : le serveur MCP est ce qui offre des éléments utiles aux clients IA. Ces éléments utiles peuvent être :

• « rechercher dans notre base de connaissances »
• « créer un problème Jira »
• « lire cette ressource approuvée »
• « retourner cette invite réutilisable »
• « appeler cette méthode de service ColdFusion »
• « résumer ce rapport interne »
• « récupérer l’état du déploiement »

Le serveur MCP est l’endroit où résident les capacités. Le client MCP est la façon dont votre application y accède. L’hôte est l’application qui coordonne l’expérience.

ColdFusion peut être le client, le serveur ou les deux

C’est là l’élément important propre à ColdFusion. La mise à jour 8 de ColdFusion 2025 prend en charge MCP dans les deux sens : client et serveur. (guides.adobe.com) Cela signifie que votre application ColdFusion peut faire deux choses différentes.

Premièrement, elle peut appeler des serveurs MCP. Par exemple, votre assistant IA ColdFusion pourrait se connecter à un serveur MCP Jira, lister les outils disponibles et appeler un outil pour consulter l’état d’un problème.

Deuxièmement, elle peut exposer un serveur MCP. Par exemple, votre application ColdFusion pourrait exposer des méthodes CFC soigneusement sélectionnées comme outils MCP afin qu’un autre hôte MCP puisse les utiliser.

Et troisièmement, en véritable mode entreprise, elle peut faire les deux. Parce qu’apparemment, une seule direction était trop généreuse.

Mode client : ColdFusion appelle un serveur MCP

Utilisez le client MCP lorsque votre application ColdFusion doit consommer des outils, des invites ou des ressources exposés par un autre serveur MCP.

Flux typique :

1. Create an MCPClient with transport configuration.
2. Call listTools() to discover available tools.
3. Call callTool() to invoke a tool.
4. Optionally call listResources(), readResource(), listPrompts(), or getPrompt().

Ce flux provient directement de la présentation MCP d’Adobe. (guides.adobe.com) Conceptuellement, le code ressemble à ceci :

<cfscript>
mcpClient = MCPClient( {
	transport : {
		type : "http",
		url : "https://mcp.example.com/mcp"
	}
} );

tools = mcpClient.listTools();

writeDump( var = tools, label = "Available MCP tools" );
</cfscript>

Ensuite, une fois que vous connaissez l’outil voulu :

<cfscript>
result = mcpClient.callTool(
	name = "getIssueStatus",
	arguments = {
		issueKey : "APP-1234"
	}
);

writeDump( var = result, label = "MCP tool result" );
</cfscript>

La forme exacte de la configuration dépend du serveur MCP et du transport que vous utilisez, alors vérifiez la documentation de ColdFusion et les exigences propres au serveur avant d’intégrer cela en production. L’idée importante est le schéma : découvrir > appeler > gérer le résultat. Ne devinez pas ce que le serveur distant expose. Demandez-lui. C’est l’un des avantages pratiques de MCP. La liste des outils provient du serveur. Votre application n’a pas besoin de coder en dur d’avance chaque détail de chaque capacité possible.

Bien sûr, comme nous sommes des développeurs, nous trouverons quand même des façons créatives de coder en dur des choses que nous ne devrions pas. La tradition compte.

Mode serveur : ColdFusion expose un serveur MCP

Utilisez le serveur MCP lorsque votre application ColdFusion doit exposer des capacités à des clients MCP externes. Flux typique :

1. Create an MCPServer with server info, capabilities, and tool/prompt/resource definitions.
2. Register CFCs as tools.
3. Define prompts and resources as needed.
4. Expose an HTTP endpoint that delegates to application.mcpServer.handleRequest().
5. External MCP clients connect to your server.

La présentation MCP d’Adobe décrit exactement ce flux pour utiliser ColdFusion comme serveur MCP. Conceptuellement, le démarrage de votre application pourrait initialiser le serveur :

<cfscript>
application.mcpServer = MCPServer( {
	serverInfo : {
		name : "Support Tools",
		version : "1.0.0"
	},
	capabilities : {
		tools : true,
		resources : true,
		prompts : true
	},
	tools : [
		{
			cfc : "tools.SupportTool",
			methods : [
				{
					method : "getTicketStatus",
					description : "Get the current status of a support ticket by ticket ID."
				}
			]
		}
	]
} );
</cfscript>

Ensuite, votre point de terminaison délègue les requêtes MCP entrantes :

<cfscript>
result = application.mcpServer.handleRequest(
	requestBody = getHttpRequestData().content
);

cfcontent(
	type = "application/json",
	reset = true
);

writeOutput( serializeJSON( result ) );
</cfscript>

Ceci ne vise pas à constituer un serveur de production complet prêt à l’emploi. Il s’agit d’une forme conceptuelle. Les détails dépendent de votre version exacte de ColdFusion, du transport, du modèle d’authentification et de la façon dont votre point de terminaison reçoit et renvoie les charges utiles MCP.

Le point architectural est le suivant : le serveur MCP encapsule vos capacités approuvées et les expose par l’intermédiaire d’un protocole standard. Cela signifie que des hôtes d’IA externes peuvent découvrir vos outils, les appeler, lire les ressources approuvées ou récupérer des modèles d’invite, sans obtenir un accès non restreint à votre application.

C’est tout l’enjeu.

Pas « le robot a tout ». Plutôt : « Voici le comptoir d’accueil. Veuillez demander poliment. Enregistrez-vous. Restez en dehors de la salle des serveurs. »

Le cycle de vie de la portée de l’application est important

Un serveur MCP ne devrait pas être recréé au hasard à chaque requête.

Les directives de cycle de vie d’Adobe indiquent qu’une fois initialisé, votre serveur MCP devrait vivre pendant toute la durée de l’application ColdFusion. Cela permet de charger les outils et les invites une seule fois, de préserver l’état et les caches du serveur, et de permettre aux clients de supposer que le serveur est disponible tant que l’application fonctionne. Adobe décrit aussi le modèle courant qui consiste à stocker l’instance partagée du serveur MCP dans application.mcpServer.

Cela correspond à la façon dont les développeurs ColdFusion pensent déjà aux services au niveau de l’application. Un modèle typique appartient à Application.cfc :

component {

	this.name = "McpDemoApplication";
	this.sessionManagement = true;

	public boolean function onApplicationStart() {
		application.mcpServer = MCPServer( {
			serverInfo : {
				name : "ColdFusion Support MCP",
				version : "1.0.0"
			},
			capabilities : {
				tools : true,
				resources : true,
				prompts : true
			},
			tools : [
				{
					cfc : "tools.SupportTool",
					methods : [
						{
							method : "getTicketStatus",
							description : "Obtenir le statut actuel d’un billet de soutien à l’aide de son ID."
						}
					]
				}
			]
		} );

		return true;
	}
}

Cela donne à votre serveur MCP un cycle de vie clair. Au démarrage de l’application, créez-le. Pendant la durée de vie de l’application, utilisez-le. Au redémarrage de l’application, recréez-le.

Si votre serveur ouvre des ressources externes, lance des processus locaux ou nécessite du nettoyage, ajoutez un crochet d’arrêt approprié dans onApplicationEnd(). La documentation sur le cycle de vie d’Adobe précise expressément qu’un nettoyage à l’arrêt peut être nécessaire pour les serveurs qui ouvrent des ressources externes, des fichiers, des tâches en arrière-plan ou des processus locaux.

Outils MCP par rapport aux outils CFC

C’est la section qui vous évitera de la confusion plus tard. Les outils CFC et les outils MCP sont liés, mais ils ne sont pas la même chose.

Outils CFC

Les outils CFC sont propres à l’agent de votre application ColdFusion. Vous enregistrez un CFC directement sur Agent(). L’agent peut demander ces méthodes. Votre application ColdFusion examine toolExecutionRequests, valide les arguments, exécute le CFC et gère le résultat.

Utilisez les outils CFC lorsque :

• l’outil se trouve à l’intérieur de l’application courante
• seule cette application en a besoin
• vous voulez l’intégration la plus simple possible
• vous n’avez pas besoin de découverte d’outils entre systèmes
• vous n’avez pas besoin que d’autres hôtes d’IA le consomment

C’est ce que nous avons couvert dans l’article précédent.

Outils MCP

Les outils MCP sont exposés par l’intermédiaire d’un serveur MCP et consommés par l’intermédiaire d’un client MCP. Utilisez les outils MCP lorsque :

• les outils se trouvent à l’extérieur de l’application courante
• plusieurs applications ou hôtes d’IA ont besoin des mêmes outils
• la découverte d’outils est importante
• les invites ou les ressources devraient aussi être partagées
• vous voulez une frontière de protocole
• la gouvernance et la vérifiabilité sont importantes
• le fournisseur de l’outil et le consommateur de l’outil sont des systèmes différents

Les outils CFC, c’est un peu comme appeler une méthode dans votre propre maison. MCP, c’est comme donner à d’autres maisons une porte d’entrée, une sonnette et une politique pour les invités. Ne confondez pas cela avec leur donner une clé du sous-sol.

Outils, invites et ressources

Les outils CFC se concentrent surtout sur les méthodes appelables. MCP est plus vaste. Il normalise trois grandes catégories : les outils, les invites et les ressources. L’aperçu MCP d’Adobe énumère précisément la découverte et l’invocation d’outils, la gestion des invites et l’accès aux ressources comme capacités MCP normalisées.

Traduisons cela.

Outils

Les outils font des choses. Par exemple :

• obtenir le statut d’un billet
• chercher des problèmes
• calculer les frais d’expédition
• créer un billet de soutien
• obtenir un résumé de compte
• dresser la liste des déploiements
• valider l’admissibilité à l’inscription

Les outils peuvent lire des données ou modifier des données. Comme toujours, les outils d’écriture exigent plus de prudence. Si l’outil change l’état du monde, exigez une autorisation, une validation, une journalisation et probablement une confirmation. Le robot n’a pas le droit de cliquer sur « Envoyer toutes les factures » simplement parce qu’il semblait confiant.

Invites

Les invites sont des modèles d’invite réutilisables. Par exemple :

• résumer un dossier de soutien
• rédiger une note de version
• transformer des journaux en résumé d’incident
• expliquer une erreur à un utilisateur non technique
• générer une liste de vérification de migration

Une invite exposée par un serveur MCP permet à plusieurs clients de réutiliser la même instruction soigneusement conçue. C’est utile, parce que la dérive des invites est bien réelle. Sans invites partagées, chaque équipe finit par écrire sa propre version de :

Please summarize this issue, but not badly.

Et tout le monde est ensuite surpris que la qualité du résultat varie. La gestion des invites MCP vous donne un endroit où définir et partager des modèles d’invites approuvés.

Ressources

Les ressources sont du contexte lisible. Par exemple :

• documentation approuvée
• état du système
• métadonnées de déploiement
• extraits de politiques
• résumés de configuration
• journaux rendus sécuritaires pour consommation par l’IA
• articles de la base de connaissances du service à la clientèle

Les ressources ne sont pas la même chose que les outils. Une ressource est quelque chose que le client peut lire. Un outil est quelque chose que le serveur peut exécuter. Cette distinction compte. Lire une page d’état approuvée n’est pas la même chose qu’appeler restartProduction(). L’un, c’est du contexte. L’autre, c’est la façon de vous faire inviter à une réunion très tendue.

Quand devriez-vous utiliser MCP?

Utilisez MCP lorsque la normalisation est plus précieuse que la simplicité locale. Les bons cas d’utilisation de MCP comprennent :

• connecter ColdFusion à un serveur MCP externe existant
• exposer les capacités d’affaires de ColdFusion à d’autres clients d’IA
• partager des outils entre plusieurs applications
• centraliser des modèles de requêtes
• exposer des ressources approuvées aux hôtes d’IA
• encapsuler des API tierces derrière une interface standard
• concevoir des flux de travail d’IA d’entreprise où l’auditabilité est importante
• permettre la découverte des outils au lieu de les coder en dur

Par exemple, imaginez une entreprise avec plusieurs applications internes :

• portail d’assistance ColdFusion
• Jira
• wiki interne
• tableau de bord de déploiement
• CRM
• archive de documents

Sans MCP, chaque application compatible avec l’IA peut avoir besoin de code d’intégration personnalisé pour chaque système. Avec MCP, chaque système peut exposer des capacités par l’entremise d’un protocole standard, et les hôtes d’IA peuvent découvrir et utiliser ces capacités de façon plus cohérente. Cela n’élimine pas le travail. Cela déplace le travail vers une meilleure forme. Ce qui, franchement, est l’essentiel de l’architecture logicielle.

Quand ne devriez-vous pas utiliser MCP?

N’utilisez pas MCP simplement parce que ça sonne impressionnant. Si votre outil vit à l’intérieur de votre application ColdFusion et que seule votre application en a besoin, un outil CFC local peut être plus simple. Par exemple, si votre assistant IA n’a besoin que de ceci :

getTicketStatus( userId, ticketId )

Et que cette méthode vit dans la même application, l’enregistrer comme outil CFC peut suffire. Ajouter MCP dans ce cas-là peut relever du cosplay architectural.

MCP ajoute de la valeur lorsque :

• il y a une frontière de système
• les outils doivent être partagés
• la découverte compte
• le partage des requêtes/des ressources compte
• plusieurs clients ont besoin d’accès
• la normalisation compte
• la gouvernance compte

Si aucune de ces conditions n’est vraie, commencez avec des outils CFC. Vous n’avez pas besoin d’un passeport pour aller de la cuisine au frigo.

MCP et sécurité

MCP est un protocole. Ce n’est pas un champ de force. Utiliser MCP ne rend pas automatiquement un outil sécuritaire. Vous avez quand même besoin :

• d’authentification
• d’autorisation
• de validation des entrées
• de filtrage des sorties
• de journalisation des audits
• de limitation du débit
• d’isolation des locataires
• de gestion des secrets
• de frontières claires entre les outils
• d’une gestion sécuritaire des erreurs
• d’une confirmation pour les actions d’écriture

Le serveur MCP devrait exposer uniquement des outils, des requêtes et des ressources approuvés. Le client MCP devrait appeler uniquement les serveurs en lesquels il a confiance. Votre application ColdFusion ne devrait pas se connecter aveuglément à des serveurs MCP aléatoires et les laisser influencer le comportement de l’application. Ce serait comme installer des extensions de navigateur au feeling. Le protocole vous donne une structure… Vous fournissez encore le jugement.

MCP et autorisation

L’autorisation doit se faire à la bonne frontière. Si ColdFusion consomme un serveur MCP, votre application doit quand même décider si l’utilisateur actuel est autorisé à demander cette capacité. Si ColdFusion expose un serveur MCP, le serveur doit authentifier les appelants et autoriser l’accès aux outils/ressources. Par exemple, si votre serveur MCP expose :

getCustomerAccountSummary

Alors il doit savoir :

• qui fait l’appel
• à quel locataire/compte ils appartiennent
• s’ils sont autorisés à accéder à ce client
• quels champs doivent être retournés
• si l’appel doit être consigné
• si des champs sensibles doivent être masqués

Ne présumez pas que l’hôte d’IA appliquera vos règles d’affaires. L’hôte peut être digne de confiance. L’hôte peut être mal configuré. L’hôte peut être une démo que quelqu’un a laissée rouler sur un portable nommé TEMP-DO-NOT-USE. Le serveur doit se protéger lui-même.

Même règle qu’avant : L’IA peut demander. ColdFusion décide. Avec MCP, on ajoute : D’autres systèmes peuvent demander. Votre serveur décide toujours.

MCP et observabilité

ColdFusion 2025 Update 8 a aussi ajouté la surveillance des services d’IA dans PMT, y compris des onglets pour les LLM, les agents, RAG, les clients MCP, les serveurs MCP, les magasins vectoriels, et un visualiseur de traces pour les requêtes d’IA. C’est important parce qu’une fois MCP ajouté, des pannes peuvent se produire à plus d’endroits.

Une requête peut impliquer :

• votre page Web
• votre agent ColdFusion
• un client MCP
• un serveur MCP externe
• une API distante derrière ce serveur
• une réponse du modèle
• le résumé du résultat de l’outil
• la validation de la sortie

Cela fait beaucoup d’éléments en mouvement. Si l’utilisateur voit :

Désolé, je n’ai pas pu terminer cette demande.

Vous devez savoir où ça a échoué. Est-ce le modèle? La poignée de main MCP? Le serveur distant? L’autorisation de l’outil? Un délai d’attente? Un mauvais argument? Une réponse mal formée? Une panne de service? Une mauvaise journée?

La journalisation et la surveillance ne sont pas facultatives. Elles sont ce qui vous évite de déboguer des flux de travail d’IA distribués en fixant le plafond et en faisant des suppositions de plus en plus précises.

Un exemple pratique de MCP

Imaginons un assistant de soutien. Dans l’article précédent, l’assistant de soutien avait un outil CFC local :

getTicketStatus( userId, ticketId )

Ça fonctionnait parce que les données des billets se trouvaient à l’intérieur de l’application ColdFusion actuelle. Imaginez maintenant que les données des billets se trouvent dans un autre système. Peut-être Jira. Peut-être ServiceNow. Peut-être une autre application ColdFusion. Peut-être un système nommé NewSupportPortal que tout le monde appelle encore « l’ancien système de billets ». Au lieu d’ajouter directement dans l’assistant une intégration propre à Jira ou à ServiceNow, vous vous connectez à un serveur MCP qui expose un outil comme :

getIssueStatus

Votre application ColdFusion peut découvrir l’outil :

<cfscript>
	mcpClient = MCPClient( {
		transport: {
			type: "http",
			url: "https://support-tools.example.com/mcp"
		}
	} );

	availableTools = mcpClient.listTools();
	writeDump( availableTools );
</cfscript>

Puis l’appeler :

<cfscript>
	toolResult = mcpClient.callTool(
		name = "getIssueStatus",
		arguments = { issueKey : "SUP-12345" }
	);
</cfscript>

Puis le résumer avec l’agent :

<cfscript>
	finalPrompt = "
		L’utilisateur a demandé : Quel est l’état de SUP-12345 ?
		Le serveur MCP a retourné : #serializeJSON( toolResult )#
		Répondez en un court paragraphe.
		N’ajoutez pas de faits qui ne se trouvent pas dans le résultat MCP.
	";

	response = agent.chat(
		finalPrompt,
		session.sessionId
	);

	writeOutput( encodeForHtml( response.message ) );
</cfscript>

Encore une fois, l’implémentation de production exacte dépendra de votre serveur, du transport, de l’authentification, de la gestion des erreurs et de la profondeur à laquelle vous intégrez les outils MCP dans le flux de travail Agent(). Mais l’idée est la même que pour les outils CFC… L’assistant identifie le besoin. L’application appelle une capacité contrôlée. Le résultat de l’outil devient la source de vérité. Le modèle explique.

MCP comme source d’outils pour Agent()

Dans l’article sur les outils CFC, l’agent pouvait demander des méthodes CFC. MCP peut aussi devenir une source d’outils. En théorie, votre agent peut être configuré pour savoir que des outils MCP externes existent et peut les demander pendant la conversation. Cela vous donne un modèle puissant :

Un utilisateur pose une question.
L’agent décide qu’un outil est nécessaire.
L’outil peut être un CFC local ou un MCP externe.
ColdFusion valide et exécute la demande.
Le résultat de l’outil revient.
L’agent explique la réponse.

Le point important est que MCP ne supprime pas les règles de sécurité de l’article précédent. Il élargit l’endroit d’où les outils peuvent provenir. Vous avez toujours besoin de :

• listes d’autorisation
• validation des arguments
• autorisation de l’utilisateur
• confirmation avant les écritures
• gestion sécurisée des erreurs
• journalisation
• filtrage des résultats

Si les outils CFC donnaient des mains à l’assistant, MCP lui donne un câble réseau. Merci de ne pas brancher ce câble à tout.

Exposer votre application ColdFusion comme serveur MCP

Maintenant, inversons la direction. Supposons que votre application ColdFusion possède des capacités d’affaires précieuses :

• obtenir le statut d’inscription
• lister les programmes disponibles
• calculer les totaux du panier
• obtenir le statut d’une commande
• lire les articles d’aide approuvés
• retourner des invites de soutien réutilisables

Vous pourriez vouloir que d’autres hôtes d’IA utilisent ces capacités. Au lieu que chaque hôte s’intègre directement à vos API internes, votre application ColdFusion peut exposer un serveur MCP. Le serveur peut fournir :

• des outils approuvés
• des ressources approuvées
• des invites approuvées

Les clients externes peuvent découvrir ce qui est disponible. C’est utile lorsque :

• votre organisation a plusieurs clients d’IA
• vous voulez une gouvernance centralisée
• vous voulez des définitions d’outils cohérentes
• vous voulez une frontière de protocole claire
• vous voulez éviter les intégrations ponctuelles
• vous voulez exposer des capacités sans exposer toute la base de code

Mais encore une fois, n’exposez pas tout. Exposez une surface soigneusement sélectionnée. Pensez « API publique », pas « vente de garage ».

Un point de terminaison MCP conceptuel

Un point de terminaison simple peut ressembler conceptuellement à ceci :

<cfscript>
	requestData = getHttpRequestData();
	responseData = application.mcpServer.handleRequest( requestBody = requestData.content );

	cfcontent(
		type = "application/json",
		reset = true
	);

	writeOutput( serializeJSON( responseData ) );
</cfscript>

Ce point de terminaison reçoit les demandes MCP et les délègue au serveur MCP de niveau application. Mais en production, ne vous arrêtez pas là. La production exige :

• authentification
• autorisation
• limites de taille des requêtes
• limitation du débit
• journalisation
• gestion des erreurs
• sécurité du transport
• frontières entre locataires
• exposition sécurisée des ressources
• configuration de déploiement claire

Le point de terminaison est la porte d’entrée. N’oubliez pas la serrure.

Les ressources ne sont pas une poubelle à documents

Comme MCP peut exposer des ressources, il peut être tentant d’exposer tout. La documentation. Les journaux. Les rapports. Les fichiers. Les notes internes. Les plans de migration à moitié terminés. Un fichier de tableur nommé final_final_really_final.xlsx.

Veuillez ne pas le faire.

Les ressources doivent être sélectionnées avec soin. Avant d’exposer une ressource via MCP, demandez-vous :

• Un client IA devrait-il être autorisé à lire cela ?
• Contient-il des secrets ?
• Contient-il des renseignements personnels ?
• L’accès dépend-il du rôle de l’utilisateur ?
• Est-ce spécifique à un locataire ?
• Est-ce à jour ?
• Est-ce sécuritaire d’en faire un résumé ?
• Devrait-il être masqué ?
• Devrait-il être disponible seulement au moyen d’un outil avec vérifications d’autorisation ?

Les ressources peuvent être utiles. Elles peuvent aussi devenir une fuite de données avec une meilleure image de marque.

Les invites sont de la logique d’affaires réutilisable… en quelque sorte

La gestion des invites MCP est intéressante parce que les invites deviennent souvent une partie du comportement d’affaires. Une invite qui dit :

Résumez cet incident pour un public de cadres.

Peut encoder les préférences de l’entreprise concernant le ton, le format, le langage sur les risques et les sections requises. Si chaque application écrit sa propre version, la qualité de sortie varie. Si un serveur MCP central expose l’invite approuvée, plusieurs clients peuvent la réutiliser.

Cela vous donne :

• de la cohérence
• des mises à jour plus faciles
• une révision centralisée
• moins de mutations d’invite copiées-collées
• moins de « pourquoi cet assistant a-t-il l’air d’un comptable pirate ? »

Traitez les invites partagées avec le même soin que vous accorderiez à des modèles partagés ou à des règles d’affaires. Ce ne sont pas que des chaînes de caractères. Ce sont des instructions qui façonnent le comportement de l’application.

MCP ne remplace pas les outils CFC

MCP n’est pas un remplacement des outils CFC. C’est une autre couche. Utilisez les outils CFC locaux pour des capacités simples, propres à l’application. Utilisez MCP pour des capacités partagées, externes, découvrables ou liées à un protocole. Parfois, vous utiliserez les deux. Par exemple :

Local CFC tool:
	getCurrentUserProfile()

External MCP tool:
	searchCompanyWiki()

External MCP resource:
	readRefundPolicy()

Agent:
	Combines profile context, wiki search, policy resource, and conversation memory.

C’est un assistant plus avancé. Et oui, ça semble compliqué. C’est pourquoi nous construisons la série une couche à la fois au lieu de commencer par un diagramme qui ressemble à une carte de métro conçue pendant une panne.

MCP ne remplace pas le RAG

MCP et RAG sont aussi différents. MCP est un protocole permettant de connecter des clients IA à des outils, des invites et des ressources. RAG est un modèle permettant de récupérer des informations pertinentes à partir de documents ou de données et de les utiliser pour ancrer les réponses du modèle. Ils peuvent fonctionner ensemble. Un serveur MCP pourrait exposer une ressource. Un outil MCP pourrait rechercher dans un système documentaire. Un pipeline RAG pourrait utiliser du contenu récupéré via MCP. Mais ce n’est pas la même chose.

MCP répond à :

How does my AI application connect to external capabilities?

RAG répond à :

How does my AI application retrieve relevant knowledge and use it in a grounded answer?

Nous couvrirons le RAG dans le prochain article. C’est là que le robot passe un examen à livre ouvert.

Erreurs courantes

Passons en revue les façons les plus simples de rendre MCP étrange.

Utiliser MCP alors qu’un outil CFC local ferait l’affaire

Si la capacité est locale et n’est nécessaire que pour une seule application, commencez par un outil CFC. MCP est utile, mais il n’est pas requis pour chaque outil. N’installez pas un pont à péage entre votre canapé et votre table à café.

Exposer trop de choses

N’exposez pas chaque CFC, chaque méthode, chaque fichier, chaque invite ou chaque ressource. Exposez des capacités approuvées. Le principe du moindre privilège s’applique toujours. Le robot n’a pas besoin d’un accès root simplement parce qu’il a appris un protocole.

Faire aveuglément confiance aux serveurs MCP distants

Si votre application ColdFusion se connecte à un serveur MCP, sachez ce qu’est ce serveur. Qui l’exploite ? Quels outils expose-t-il ? Quelles données retourne-t-il ? Quelle authentification exige-t-il ? Que se passe-t-il lorsqu’il échoue ? Que consignez-vous ? Qu’envoyez-vous ?

« Je l’ai trouvé sur GitHub » n’est pas une évaluation des risques liés à un fournisseur.

Oublier les limites de locataire

Les applications multi-locataires ont besoin de limites rigoureuses. Si un serveur MCP expose des données de clients ou d’organisations, chaque appel doit appliquer l’isolation des locataires. Ne laissez pas un flux de travail IA devenir la route panoramique qui contourne votre modèle d’autorisations.

Retourner des réponses énormes

Les outils et ressources MCP devraient retourner le minimum de données utile. Les grosses réponses augmentent les coûts, la latence, la pression sur le contexte et la confusion. Aucun modèle n’a besoin d’une réponse JSON de 9 Mo à moins que votre objectif ne soit de faire un test de stress de la facturation.

Sauter l’observabilité

Une fois MCP en jeu, les défaillances s’étendent sur plusieurs systèmes. Consignez les requêtes. Consignez les noms des outils. Consignez des résumés sûrs des arguments. Consignez les temps. Consignez les erreurs. Utilisez PMT ou toute autre stratégie de surveillance qui convient à votre environnement.

Vous ne pouvez pas corriger ce que vous ne pouvez pas voir. Vous ne pouvez pas non plus l’expliquer à votre patron, ce qui est souvent pire.

Ne pas confirmer les actions d’écriture

Si un outil MCP peut envoyer des courriels, créer des enregistrements, annuler des choses, facturer de l’argent ou apporter des changements publics, exigez une confirmation et une autorisation. Le simple fait qu’un outil se trouve derrière MCP ne le rend pas moins dangereux. Cela rend seulement le danger plus standardisé.

Une meilleure première fonctionnalité MCP

Une bonne première fonctionnalité MCP est en lecture seule et présente un faible risque. Par exemple :

• lister les outils d’un serveur MCP interne connu
• appeler un outil d’état en lecture seule
• récupérer un modèle d’invite approuvé
• lire une ressource de documentation sécurisée
• rechercher dans un wiki d’entreprise avec un accès limité
• exposer une méthode CFC ColdFusion en lecture seule comme outil MCP

Évitez que votre première fonctionnalité MCP soit :

• envoyer des courriels
• supprimer des enregistrements
• émettre des remboursements
• modifier des autorisations
• modifier les paramètres de production
• exposer des journaux bruts
• exposer des lectures arbitraires de fichiers
• exposer l’exécution SQL

Commencez par la visibilité. Puis passez à l’action. Cette approche nous a bien servi auparavant, surtout parce que l’approche opposée a créé des pannes aux noms évocateurs.

La suite

À ce stade, notre assistant IA ColdFusion a pas mal mûri. Nous avons maintenant :

ChatModel() : appels IA de base sans état.
Agent() avec mémoire : contexte de conversation et continuité par utilisateur.
Outils CFC : capacités locales de l’application.
MCP : outils, invites et ressources normalisés à travers les frontières du système.

C’est une base solide. Mais nous avons encore un autre gros problème. Et si l’assistant devait répondre à des questions à partir de nos propres documents, et non de l’état de l’application ? Pas des résultats d’outils. Pas du statut d’un billet. Des documents. Des politiques. Des guides. Des articles de base de connaissances. Des manuels. De la documentation interne qui a peut-être été rédigée par quelqu’un qui considérait les paragraphes comme facultatifs.

C’est là que le RAG entre en jeu.

Dans le prochain article, nous ajouterons la génération augmentée par récupération et apprendrons à l’assistant à répondre à partir de notre propre contenu plutôt que de s’appuyer sur la mémoire du modèle, des impressions vagues ou sur ce qu’il a lu sur Internet avant le dîner.

Réflexion finale

MCP n’est pas de la magie. Ce n’est pas un modèle de sécurité en soi. Ce n’est pas un remplacement des outils CFC. Ce n’est pas une raison d’exposer tout ce qui se trouve dans votre application. C’est un protocole standard pour connecter les clients IA à des outils, des invites et des ressources de manière cohérente et vérifiable. C’est précieux. Surtout lorsque vos flux de travail IA doivent franchir les frontières entre les applications. Utilisez les outils CFC lorsque la capacité se trouve dans votre application. Utilisez MCP lorsque la capacité doit être partagée, découverte, encadrée ou accessible entre les systèmes.

Gardez les limites claires. Validez tout. Autorisez tout. Consignez suffisamment d’informations pour déboguer l’étrangeté inévitable. Et rappelez-vous : les outils CFC ont donné des mains à l’assistant. MCP lui donne un passeport. ColdFusion décide toujours où il est autorisé à aller.