Skip to content
🚀 EDDI 6.5.0

19 fournisseurs LLM, des bases de connaissances qui explorent votre site et lisent vos fichiers, et des conversations qui suivent les versions compatibles des agentsNouveautés

Cloud Géré Démarrer
Toutes les intégrations
Systèmes d'entrepriseOpenAPI 3.0 / 3.1

OpenAPI

Transformer toute API REST décrite en OpenAPI 3.0 ou 3.1 en agent doté d'outils, sans écrire de code, et placer les appels à conséquences derrière une validation humaine.

Ce que vous obtenez

  • Un agent appelant l'API, généré à partir de la spécification : configurations d'appels HTTP regroupées par tag, le pipeline et le déploiement
  • Un filtrage des endpoints, un remplacement de l'URL de base et la propagation de l'en-tête d'authentification
  • La possibilité d'ajouter les outils d'un serveur MCP à côté de ceux générés
  • Des outils que vous pouvez relire, comparer et versionner, car ce sont des configurations

Fonctionnement dans EDDI

  1. Fournir la spécification OpenAPI à EDDI via l'outil MCP create_api_agent ou POST /administration/agents/setup-api.
  2. Placer sur liste d'autorisation les opérations que l'agent doit avoir. Un endpoint non déclaré ne peut pas être appelé.
  3. EDDI génère les configurations d'appels HTTP, construit le pipeline complet et déploie l'agent.
  4. Conserver les identifiants sous forme de références ${vault:...}.
  5. Protéger les écritures avec http.post:*, http.put:*, http.patch:*, http.delete:* et exempter les lectures avec http.get:*.

Configuration

Tirée de la documentation d'EDDI. Les espaces réservés comme your-agent-id sont à remplacer par vos propres valeurs.

httpCalls configuration (the model the generated tools use)Le modèle httpCalls à partir duquel les outils générés sont construits. Écrit ici à la main pour montrer les champs.
{
  "targetServerUrl": "https://api.example.com/v1",
  "httpCalls": [
    {
      "name": "list-open-orders",
      "saveResponse": true,
      "responseObjectName": "order",
      "request": {
        "method": "GET",
        "path": "/orders",
        "queryParams": { "status": "open" },
        "headers": { "Authorization": "Bearer ${vault:orders-api-token}" }
      }
    }
  ]
}
agent configuration (hitlConfig)Valider chaque appel qui modifie l'état, laisser passer les lectures.
{
  "hitlConfig": {
    "toolApprovals": {
      "requireApproval": [
        "http.post:*",
        "http.put:*",
        "http.patch:*",
        "http.delete:*"
      ],
      "exempt": [
        "http.get:*"
      ],
      "approvalTimeout": "PT30M",
      "timeoutPolicy": "AUTO_REJECT"
    }
  }
}

Gouvernance

  • Les motifs de validation peuvent cibler ce qu'un outil appelle (http.post:*), ce qui reste correct lorsqu'un operationId change.
  • Les appels sortants sont protégés par la plateforme contre le SSRF et le path traversal.
  • Via REST, setup-api accepte une hitlConfig : un agent peut ainsi être provisionné avec ses outils d'écriture protégés dès la première version. L'outil MCP ne peut pas la définir.
  • Les décisions sont consignées dans le journal d'audit.

Bon à savoir

  • Un outil d'écriture généré prend l'ensemble du corps de la requête dans un seul paramètre requestBody.

Vous voulez qu'on le construise et l'exploite pour vous ?

EDDI Solutions construit et maintient des connecteurs, exploite EDDI en instance managée ou co-exploitée, et vous accompagne dans votre propre cloud ou sur site.

Contacter EDDI Solutions ↗

Intégrations associées

La configuration et le comportement décrits sur cette page suivent la documentation d'EDDI, vérifiée le 2026-10-14. Les noms de champs et les valeurs par défaut peuvent changer d'une version à l'autre : confirmez-les dans la documentation de votre version.