Un outil MCP exposé par un serveur interne pour rechercher des produits accepte cinq paramètres, dont trois sont facultatifs : une catégorie, une fourchette de prix, un critère de tri. Appeler cet outil depuis du code PHP qui orchestre l’agent, avec un tableau positionnel classique, oblige à respecter un ordre précis et à passer des valeurs par défaut explicites même quand elles ne servent à rien pour l’appel en cours.
Les arguments nommés, introduits par PHP 8.0, changent la donne pour ce type d’appel interne : ils permettent de ne préciser que les paramètres réellement utiles, dans n’importe quel ordre, sans sacrifier la lisibilité.
Le problème du tableau positionnel
Une fonction PHP qui prépare l’appel à un outil MCP ressemble souvent à ceci, avec une signature à plusieurs paramètres optionnels :
function rechercherProduits(
string $motCle,
?string $categorie = null,
?float $prixMin = null,
?float $prixMax = null,
string $tri = 'pertinence'
): array {
// construit la charge utile envoyée à l'outil MCP
}
Appeler cette fonction pour ne préciser que le tri, sans catégorie ni fourchette de prix, oblige en position classique à écrire trois valeurs null intermédiaires :
rechercherProduits( 'chaussure', null, null, null, 'prix_croissant' );
Cette écriture ne dit rien, à la lecture, de l’intention réelle de l’appel. Il faut rouvrir la signature de la fonction pour comprendre à quoi correspond chaque null.
Réécrire l’appel avec des arguments nommés
Avec les arguments nommés, seul le paramètre utile apparaît, dans l’ordre qui convient à la lecture :
rechercherProduits(
motCle: 'chaussure',
tri: 'prix_croissant'
);
L’appel devient auto-documenté : un développeur qui découvre cette ligne comprend immédiatement l’intention, sans consulter la déclaration de la fonction. C’est un gain de lisibilité direct sur le code d’orchestration d’un agent, souvent traversé rapidement lors d’une revue.
Mélanger arguments positionnels et nommés
PHP autorise un mélange des deux styles, à condition que les arguments positionnels précèdent toujours les arguments nommés :
rechercherProduits( 'chaussure', categorie: 'running', tri: 'prix_croissant' );
Construire la charge utile de l’outil MCP à partir des arguments
Le corps envoyé au serveur MCP se construit ensuite en ne transmettant que les champs réellement définis, ce qui évite d’envoyer des paramètres vides que le serveur devrait ignorer de son côté :
function rechercherProduits(
string $motCle,
?string $categorie = null,
?float $prixMin = null,
?float $prixMax = null,
string $tri = 'pertinence'
): array {
$arguments = array_filter( array(
'mot_cle' => $motCle,
'categorie' => $categorie,
'prix_min' => $prixMin,
'prix_max' => $prixMax,
'tri' => $tri,
), static fn( $valeur ) => null !== $valeur );
return appelerOutilMcp( 'recherche_produits', $arguments );
}
Limites de l’approche
Les arguments nommés supposent que les noms des paramètres restent stables dans le temps : renommer un paramètre casse tous les appels qui l’utilisaient par son nom, alors qu’un appel positionnel aurait continué à fonctionner tant que l’ordre était respecté. Cette rigidité est plutôt un avantage pour du code interne à une équipe : elle force à traiter le renommage comme un changement de contrat, pas comme un détail.
- Réserver les arguments nommés aux fonctions dont la signature est stabilisée
- Documenter dans le nom du paramètre l’unité attendue quand elle n’est pas évidente
- Éviter de nommer des paramètres dont le rôle change selon le contexte d’appel
Un appel lisible sans consulter la déclaration de la fonction fait gagner plus de temps en relecture qu’en écriture initiale : c’est là que les arguments nommés rendent le plus service.
En pratique
Pour un outil MCP à plusieurs paramètres optionnels, les arguments nommés évitent le bruit visuel des valeurs par défaut inutiles et rapprochent l’appel PHP de la lisibilité d’un appel en langage naturel, ce qui compte particulièrement dans du code d’orchestration appelé à évoluer souvent.
