Uptime Formation > IA pour les devs > Jour 1 - Fondamentaux > 3 - TP Tool Calling et MCP

3 - TP Tool Calling et MCP

Observer ce que fait l’agent

⏱ 45 min

Objectif

Configurer des MCPs utiles et observer concrètement leur impact sur le comportement de l’agent.

Étape 1 : Observer les tool calls

Lancer l’agent :

opencode       # tool calls visibles nativement
# ou
codex
            # Codex : tool calls visibles nativement
            # Claude Code : claude --verbose

Prompt simple :

>Liste tous les endpoints de l'API

Observer dans les logs :

[TOOL] read_file(filePath="src/api/routes.py")
[TOOL] grep(pattern="@app\.(get|post|put|delete)", output="content")

Grille d’observation :

Critère	Oui/Non	Notes
Lit les fichiers avant de répondre
Utilise plusieurs outils en séquence
Vérifie les résultats
Demande clarification si ambigu

Étape 2 : Compter les appels

Prompt complexe :

>Ajoute un endpoint GET /users/{id}/posts
>qui retourne les posts d'un utilisateur
>avec pagination (limit, offset)

Tracer les appels :

┌─────────────────────────────────────────────┐
│ Appel #1: read_file(src/api/routes.py)      │
│ Appel #2: read_file(src/models/post.py)     │
│ Appel #3: read_file(src/models/user.py)     │
│ Appel #4: write_file(src/api/routes.py)     │
│ Appel #5: run_command(pytest tests/)        │
└─────────────────────────────────────────────┘

Question : L’agent a-t-il modifié les bons fichiers ?

Étape 3 : Recherche web — MCPs ou natif ?

Claude Code et Codex ont la recherche web intégrée nativement — rien à faire.

OpenCode ou Roo Code n’ont pas de recherche intégrée. Il faut ajouter un MCP comme ddg_search.

Opencode :

{
"mcp: {
"ddg_search": {
      "type": "local",
      "enabled": true,
      "command": [
        "npx",
        "-y",
        "@oevortex/ddg_search"
      ]
    }
}
}

Étape 4 : context7 — ancrer l’agent dans la vraie doc

Quand l’agent travaille avec une librairie dont il peut avoir une connaissance périmée, context7 lui injecte la documentation réelle à jour.

Configurer context7 :

Opencode :

{
"mcp: {
"context7": {
      "type": "local",
      "enabled": true,
      "command": [
        "npx",
        "-y",
        "@upstash/context7-mcp"
      ]
    }
}
}

Roo Code:

Installer via le Roo Marketplace en cliquant sur les petits cubes en haut

Codex :

codex mcp add context7 -- npx -y @upstash/context7-mcp

Redémarrer l’agent, puis tester :

Avec la question de votre choix :

>utilise context7
>Comment migrer de on_event vers lifespan dans FastAPI ?

Observer le pattern :

[TOOL] context7_resolve-library-id [libraryName=fastapi]
[TOOL] context7_query-docs [libraryId=/tiangolo/fastapi, query=lifespan startup shutdown]

L’agent répond avec la vraie API FastAPI 0.115, pas ce qu’il “croit” savoir

Étape 5 : Playwright — voir et interagir avec Microblog

On peut utiliser directement le MCP Chrome DevTools ou Playwright.

Pourquoi Playwright plutôt qu’un screenshot ?

Playwright renvoie une représentation textuelle du DOM, pas une image. Économie de tokens massive, et le LLM peut raisonner dessus sans vision.

Configurer le MCP Playwright :

Codex :

codex mcp add playwright -- npx -y @playwright/mcp

Opencode :

{
"mcp: {
"playwright": {
      "type": "local",
      "enabled": true,
      "command": [
        "npx",
        "-y",
        "@playwright/mcp"
      ]
    }
}
}

L’exercice :

Avec Microblog qui tourne en local, demandez à l’agent d’interagir avec la page.

Observer les appels :

[TOOL] playwright_navigate(url="http://localhost:<PORT>")
[TOOL] playwright_snapshot()
[TOOL] playwright_click(ref="textarea.prompt-input")
[TOOL] playwright_fill(value="Explique le tool calling en 2 phrases")
[TOOL] playwright_click(ref="button[type=submit]")
[TOOL] playwright_snapshot()

⚠️ Codex CLI + sandbox + Playwright : Le mode sandbox de Codex (--approval-mode full-auto) empêche le lancement de Playwright. Si le MCP Playwright ne répond pas sous Codex, désactivez le sandbox ou passez en mode auto-edit.

Mode headless : Par défaut, Playwright tourne sans ouvrir de fenêtre (headless). Pour voir le navigateur s’animer en temps réel, ajoutez "headless": false dans la config du MCP :
{
  "command": ["npx", "-y", "@playwright/mcp", "--headless=false"]
}
Utile pour déboguer ou montrer ce que l’agent fait visuellement.

Étape 6 : GitHub — gh CLI ou MCP ?

Philosophie bash vs MCP. Les deux fonctionnent.

Approche 1 — gh CLI (bash)

Si gh est installé et authentifié sur votre machine, l’agent peut l’utiliser directement sans aucune config :

>Utilise la CLI gh
>Liste les 5 dernières issues ouvertes sur miguelgrinberg/microblog
>et résume les changements de chacune

Avantages : zéro config, transparent, aucune surface d’attaque supplémentaire.
Limite : l’agent a accès à tout ce que gh peut faire — avec vos permissions complètes.

Approche 2 — MCP GitHub

Le MCP GitHub expose des outils typés (create_issue, list_pull_requests, get_file_contents…) avec un périmètre configurable.

# ~/.config/opencode/mcp.yaml
mcpServers:
  github:
    command: npx
    args: ["-y", "@modelcontextprotocol/server-github"]
    env:
      GITHUB_PERSONAL_ACCESS_TOKEN: ${GITHUB_TOKEN}

>Utilise le MCP github
>Liste les 5 dernières issues ouvertes sur miguelgrinberg/microblog
>et résume les changements de chacune

Avantages : interface propre, token avec permissions fines (lecture seule si vous voulez), contexte riche.
Limite : le MCP lit les issues et PRs — qui peuvent contenir des tentatives de prompt injection (voir section risques dans le cours).

L’exercice

Faites les deux, comparez :

Avec gh : créez une issue sur un de vos repos
Avec le MCP : listez les PRs ouvertes et demandez un résumé

Question : Laquelle des deux approches vous semble plus adaptée à votre contexte ? Pourquoi ?

Permissions

Opencode

Vous pouvez définir des autorisations globalement (avec *) et remplacer des outils spécifiques.

opencode.json :

{
  "$schema": "https://opencode.ai/config.json",
  "permission": {
    "*": "ask",
    "bash": "allow",
    "edit": "deny"
  }
}

{
  "$schema": "https://opencode.ai/config.json",
  "permission": "allow"
}

OpenAI Codex CLI

# Mode suggestion (défaut) — demande approbation à chaque action
codex "ajoute la pagination"

# Auto-edit — approuve les modifications de fichiers, demande pour les commandes shell
codex --approval-mode auto-edit "$(cat TASK.md)"

# Full-auto — approuve tout, y compris les commandes shell arbitraires
codex --approval-mode full-auto "$(cat TASK.md)"

full-auto ne s’utilise qu’à l’intérieur d’un sandbox. Jamais sur votre machine principale.

Claude Code

# Mode interactif normal — Claude demande avant chaque action sensible
claude

# Skipper TOUTES les permissions — à n'utiliser qu'en sandbox
claude --dangerously-skip-permissions

--dangerously-skip-permissions approuve automatiquement : lecture/écriture de fichiers, exécution de commandes shell, appels réseau. Le nom est volontairement alarmant.

Bonus : autres MCPs utiles

Une fois que vous êtes à l’aise avec le pattern MCP, voici ce que la communauté utilise le plus.

Communication

Slack

slack:
  command: npx
  args: ["-y", "@modelcontextprotocol/server-slack"]
  env:
    SLACK_BOT_TOKEN: ${SLACK_BOT_TOKEN}
    SLACK_TEAM_ID: ${SLACK_TEAM_ID}

L’agent peut envoyer des messages, lire des canaux, rechercher dans l’historique. Utile pour des notifications automatiques en fin de tâche.

Telegram
Plusieurs MCPs communautaires disponibles — pratique si votre équipe est sur Telegram plutôt que Slack.

Filesystem étendu — accès à des dossiers en dehors du projet courant (logs système, exports, etc.).

Rappel sécurité : Un package compromis s’exécute avec vos permissions.

Prochain module

Module 4 : Bonnes Pratiques - AGENTS.md, Makefile, Docker, README.