Après mise à jour session tools OpenAI Agents API le 30 octobre 2026 : quand le JSON Schema Function et MCP prend-il effet ?

Avant, on créait souvent une session avec tools figés pour toute la durée du ticket. Depuis le 30 octobre, vous pouvez changer tout le contrat d'outils en cours de route — MCP lecture seule vers function avec approbation, ou allowed_tools plus strict. Le moment et la sémantique de remplacement doivent être codés dans votre machine d'états, pas devinés.

Ce qui a changé le 30 octobre

Entrée changelog (API : v1/agents, v1/agents/sessions) — formulation bêta au 10/11/2026 :

• Mise à jour de tools sur session existante.
• Updates replace the full tool list — pas de merge par name.
• Function tools and MCP servers change on the next model call.
• Built-in tools change by the next turn — un cran après function/MCP, frontière = tour.

Le même jour : compaction en arrière-plan par défaut, auto_review, etc. — orthogonal à tools : changer le contrat ne change pas la politique de compaction du transcript.

Remplacement complet, pas de diff

« Mettre à jour tools », c'est publier une nouvelle version OpenAPI, pas patcher l'ancienne :

{
  "session_id": "sess_01HZZ...",
  "tools_before_count": 3,
  "tools_after_payload": {
    "tools": [
      {
        "type": "function",
        "name": "approve_refund",
        "description": "Human-approved refund only after ticket review.",
        "parameters": {
          "type": "object",
          "properties": {
            "ticket_id": { "type": "string" },
            "amount_cents": { "type": "integer", "minimum": 0 }
          },
          "required": ["ticket_id", "amount_cents"],
          "additionalProperties": false
        }
      },
      {
        "type": "mcp",
        "server_label": "crm_readonly",
        "transport": {
          "type": "http",
          "server_url": "https://crm.example.com/mcp"
        },
        "connection_origin": "service",
        "allowed_tools": ["get_customer", "list_orders"]
      }
    ]
  },
  "note": "Les anciennes functions absentes de tools_after sortent du contrat session"
}

Pousser seulement les nouveautés en espérant garder le reste — au prochain model call la surface d'outils est plus petite, le modèle peut appeler un name disparu. Avant publication : hash du tableau tools, allowlist, chaque parameters via validation schema.

Quand chaque type d'outil s'applique

« model call » et « tour » ne sont pas le même compteur dans le flux d'événements Agents. Juste après la mise à jour tools, un requires_action peut encore venir du vieux schema — validez avec le snapshot schema au moment de création de l'appel, pas les parameters fraîchement uploadés.

Écrire le schema dans le nouveau tableau tools

function reste comme Responses / Chat Completions : avec strict: true, sous-ensemble structured output OpenAI (pas de oneOf, etc. — voir Function Calling). Les entrées MCP n'ont pas de parameters, mais allowed_tools doit rester aligné sur les inputSchema du serveur — la mise à jour session tools ne modifie pas le schema serveur.

{
  "version_tag": "tools-v4",
  "function_example": {
    "type": "function",
    "name": "set_priority",
    "parameters": {
      "type": "object",
      "properties": {
        "priority": { "type": "string", "enum": ["low", "normal", "high"] }
      },
      "required": ["priority"],
      "additionalProperties": false
    }
  },
  "mcp_example": {
    "type": "mcp",
    "server_label": "internal_ops",
    "allowed_tools": ["run_playbook"],
    "required": false
  },
  "client_mirror": {
    "last_published_version": "tools-v4",
    "schemas_by_name": {
      "set_priority": { "ref": "parameters above" }
    }
  }
}

Source de vérité unique dans le dépôt (JSON ou composants OpenAPI) : à chaque mise à jour session, générer la liste tools complète — pas « session en v4, worker valide encore v3 ».

Appels en cours et validation locale

Sur le chemin function, le harness émet agent.session.requires_action. Avant de renvoyer tool_result :

1. Via call_id, retrouver la version schema à la création (ou name + version_tag monotone).
2. Valider arguments contre JSON Schema ; en échec, error dans le result, pas de modification silencieuse.
3. Après remplacement complet et name retiré : refuser les appels tardifs et journaliser un JSON d'audit.

{
  "inflight_call": {
    "call_id": "call_8f2a",
    "name": "get_customer",
    "schema_version": "tools-v3",
    "arguments": { "customer_id": "cust_9" }
  },
  "session_tools_version_now": "tools-v4",
  "action": "validate_against_v3_then_execute_or_reject"
}

MCP passe souvent sans vos required_actions ; un allowed_tools resserré ne s'applique qu'au prochain model call. Validez toujours structuredContent contre outputSchema — MCP outputSchema.

Compaction et auto_review le même jour

Changelog 2026-10-30 : compaction en arrière-plan par défaut ; review: "auto_review" peut approuver certaines requêtes d'outil côté modèle. Cela ne change pas « remplacer la liste tools complète ». Après compaction, la liste tools dernière publiée sur la session fait foi — ne parsez pas de schema depuis les items compactés. auto_review juge intention et risque, ne remplace pas la validation parameters.

Vérifier dans la boîte à outils JSON

1. function_example.parameters et exemple arguments dans validation schema.
2. Function Calling pour strict et règles du sous-ensemble.
3. Outil MCP : champs allowed_tools et inputSchema.
4. JSON tools complet : formatage puis diff avant publication.

FAQ

Mise à jour tools : merge ou remplacement complet ?

Remplacement complet. Omission = suppression.

Quand le nouveau schema s'applique-t-il ?

function/MCP : prochain model call ; built-in : prochain tour.

allowed_tools est-il un schema ?

Non — liste de découverte ; contrat d'entrée = MCP inputSchema.

Conflit avec compaction ?

Non. Compacter l'historique ; tools par mise à jour explicite.

Valider arguments en local ?

Oui — surtout au tour de transition après changement de liste.

Conclusion

Au 10/11/2026, la mise à jour session tools Agents API officialise le changement dynamique de contrat : liste complète remplacée, function/MCP au prochain model call, built-in au tour suivant, et snapshots schema versionnés dans le worker pour les appels en cours. Prochaine étape en staging : « appel v3 → passage v4 → retour result » et vérifier que le validateur n'applique pas le nouveau schema à l'ancien appel.

Outils associés

Articles associés