Exécuter les fonctions outils

Claude a répondu avec une demande d’outil ; la balle est dans votre camp. Votre serveur doit exécuter l’outil demandé et renvoyer les résultats — une étape qui implique l’extraction des parties ToolUse de la réponse, l’exécution des fonctions appropriées, et le formatage correct des résultats. C’est le cœur opérationnel du Tool Use, et cette leçon le construit fonction par fonction.

Gérer les demandes multiples

Première réalité à intégrer dans le design : Claude peut envoyer plusieurs parties ToolUse dans une seule réponse — deux calculs indépendants, par exemple. Votre code doit gérer cette possibilité dès le départ ; c’est pourquoi nous traiterons systématiquement des listes de demandes, jamais une demande isolée.

Extraire les parties ToolUse

Créez une fonction pour traiter toutes les parties renvoyées :

def run_tools(parts):
    tool_requests = [part for part in parts if "toolUse" in part]
    tool_result_parts = []

    for tool_request in tool_requests:
        tool_use_id = tool_request["toolUse"]["toolUseId"]
        tool_name = tool_request["toolUse"]["name"]
        tool_input = tool_request["toolUse"]["input"]

La compréhension de liste fait le tri : une réponse de Claude mélange parties texte et parties outil, et on ne garde que les dictionnaires contenant une clé "toolUse". De chaque demande, on extrait le triplet qui suffit à tout : l’identifiant (pour l’appariement), le nom (pour le routage), les arguments (pour l’exécution).

Exécuter les outils

Créez une fonction d’acheminement pour exécuter l’outil demandé :

def run_tool(tool_name, tool_input):
    if tool_name == "get_current_datetime":
        return get_current_datetime(**tool_input)
    else:
        raise Exception(f"Nom d'outil inconnu : {tool_name}")

Le détail clé : utilisez **tool_input pour déployer le dictionnaire d’arguments dans votre fonction — Claude renvoie toujours les arguments sous forme de dictionnaire, et le double astérisque transforme {"date_format": "%H:%M"} en get_current_datetime(date_format="%H:%M"). La branche else n’est pas décorative : un nom d’outil inconnu doit éclater en erreur explicite, pas se perdre dans un retour silencieux.

Créer les parties ToolResult

Après l’exécution, formatez la réponse comme une partie ToolResult avec trois propriétés requises :

• toolUseId : doit correspondre à l’ID de la demande originale
• content : la sortie de votre outil, sérialisée en chaîne
• status : "success" ou "error"

Ce triplet est le miroir exact de la demande : l’ID referme la boucle, le contenu porte la donnée, le statut qualifie l’issue.

Gestion des erreurs

Encadrez l’exécution dans un try-except — car Claude est remarquablement intelligent face aux erreurs et peut ajuster son approche, à condition qu’on les lui transmette :

try:
    tool_output = run_tool(tool_name, tool_input)
    tool_result_part = {
        "toolResult": {
            "toolUseId": tool_use_id,
            "content": [{"text": json.dumps(tool_output)}],
            "status": "success"
        }
    }
except Exception as e:
    tool_result_part = {
        "toolResult": {
            "toolUseId": tool_use_id,
            "content": [{"text": f"Erreur : {e}"}],
            "status": "error"
        }
    }

Lisez bien la branche except : l’exception ne remonte pas, elle devient un résultat — message d’erreur en contenu, statut "error". C’est le choix d’architecture qui rend le système résilient : au lieu de faire planter la conversation, l’erreur repart vers Claude, qui la lit et retente avec des arguments corrigés. Vos messages d’erreur, écrits avec soin dès les fonctions outils, trouvent ici leur destinataire.

Comprendre les IDs d’outils

Le système d’ID devient important quand Claude demande plusieurs outils en parallèle. Chaque demande reçoit un ID unique, et vos résultats doivent inclure les IDs correspondants pour que Claude sache quel résultat correspond à quelle demande — croisez deux IDs, et le modèle raisonnera sur des données attribuées aux mauvais outils, sans qu’aucune erreur ne vous prévienne. C’est la règle d’appariement la plus stricte du protocole : un résultat par demande, chacun sous le bon identifiant.

Points clés à retenir

• Traitez toujours des listes de demandes : Claude peut demander plusieurs outils d’un coup
• Le triplet extrait de chaque ToolUse : ID (appariement), nom (routage), input (exécution)
• **tool_input déploie les arguments ; la branche else fait éclater les noms inconnus
• Les exceptions deviennent des ToolResult status: "error" — Claude lit l’erreur et se corrige
• Un résultat par demande, sous l’ID exact : l’appariement croisé est une corruption silencieuse