Outils serveur et serveurs MCP

Un outil serveur est un outil que la passerelle exécute elle-même, à l’intérieur de la requête. Vous le déclarez dans tools, à côté de vos propres fonctions, sous la forme {"type": "autonomousrelay:<name>"} ; quand le modèle l’appelle, la passerelle l’exécute, remet le résultat au modèle et poursuit, et vous ne recevez que la réponse finale. Il en existe trois sortes : les outils intégrés, les serveurs MCP de votre organisation, et les plugiciels du marché que vous avez installés.

Outils intégrés

{
  "model": "anthropic/claude-sonnet-5",
  "messages": [{"role": "user", "content": "What day is it in Toronto, and which Claude models can I use?"}],
  "tools": [
    {"type": "autonomousrelay:datetime", "parameters": {"timezone": "America/Toronto"}},
    {"type": "autonomousrelay:experimental__search_models"}
  ]
}

• autonomousrelay:datetime — la date et l’heure courantes. parameters.timezone fixe le fuseau par défaut (IANA, p. ex. America/Toronto) ; le modèle peut en nommer un autre ; sinon, UTC.
• autonomousrelay:experimental__search_models — le catalogue, cherché par des mots de l’identifiant ou du nom d’un modèle (query, au plus limit 10) : identifiants, noms et longueurs de contexte.

Ces deux outils sont ceux qui fonctionnent aujourd’hui. Le catalogue (GET /v1/tools, et la page Outils de votre espace de travail) énumère aussi web_search, web_fetch, advisor, subagent, fusion, shell, bash, apply_patch, image_generation et tool_search, chacun marqué comme non offert. Une requête qui déclare l’un d’eux est refusée par un 400 qui le nomme, jamais servie en silence sans l’outil. PUT /v1/tools avec {"disabled": [...]} désactive un outil existant pour l’organisation (un siège doté de config:write) ; une requête qui le déclare ensuite est refusée.

Vos propres serveurs MCP

{
  "name": "crm",
  "url": "https://mcp.example.com/mcp",
  "allowed_tools": ["search_accounts", "get_account"],
  "header_name": "Authorization",
  "header_value": "Bearer ..."
}

Enregistrez un serveur une fois : un name (1 à 32 lettres minuscules, chiffres ou traits d’union), son URL https publique, au besoin les outils qu’il peut offrir et un en-tête d’identification. La valeur de l’en-tête est scellée à l’arrivée et jamais réaffichée (l’API en renvoie les quatre derniers caractères) ; jusqu’à 20 serveurs par organisation. GET /v1/mcp-servers/:id/tools demande ses outils au serveur en direct, ce qui vérifie l’enregistrement. L’onglet Serveurs MCP de la page Outils fait de même.

"tools": [{"type": "autonomousrelay:mcp", "server": "crm", "allowed_tools": ["search_accounts"]}]

Dans une requête, cette déclaration offre au modèle les outils du serveur comme des fonctions nommées mcp__<server>__<tool> ; la passerelle appelle le serveur avec l’identifiant conservé et remet le résultat au modèle. Au plus cinq serveurs par requête. Un nom non enregistré est un 404, un serveur désactivé un 403, et un serveur qui ne peut pas énumérer ses outils un 502 — avant tout appel à un fournisseur.

Plugiciels du marché

"tools": [{"type": "autonomousrelay:plugin", "plugin": "slack", "allowed_tools": ["search_messages"]}]

Un plugiciel installé est un serveur MCP hébergé par son développeur. Ses outils parviennent au modèle sous plugin__<slug>__<tool>, appelés avec l’identifiant que détient l’installation ; un plugiciel non installé est un 404, un plugiciel désactivé un 403. Au plus cinq par requête. L’installation se fait depuis l’onglet Plugiciels de la page Outils ; en créer un fait l’objet de son propre guide.

Tous les outils connectés

"tools": [{"type": "autonomousrelay:connected"}]

Offre au modèle toutes les connexions de votre organisation — chaque plugiciel installé et chaque serveur MCP enregistré — sans les nommer, si bien qu’un robot conversationnel profite d’un connecteur dès le jour où il est connecté. include et exclude prennent des identifiants de plugiciels et des noms de serveurs MCP pour le restreindre. Une déclaration explicite autonomousrelay:plugin ou autonomousrelay:mcp dans la même requête l’emporte pour sa connexion.

• Lecture seule par défaut. Seuls les outils de lecture d’une connexion sont offerts : un outil compte comme tel quand il se déclare en lecture seule et, pour un plugiciel, que son manifeste le confirme. Un outil d’écriture n’est offert que si writes le nomme exactement comme le modèle le voit (plugin__zendesk__add_note), et une écriture nommée attend toujours une personne : la requête doit porter un run_id dont l’agent a une politique d’approbation, sinon elle est refusée avec un 400.
• Une connexion qui ne fonctionne pas est ignorée, sans erreur : jamais connectée, expirée, désactivée, ou sans réponse en cinq secondes. La réponse vient des autres, ou du modèle seul. L’en-tête de réponse X-Autonomous-Relay-Connected-Tools indique ce qui a servi et ce qui a été ignoré (used=notion;skipped=slack:expired), tout comme agentrouter_metadata.connected_tools quand vous demandez les métadonnées.
• Votre organisation est avertie, pas votre client. Une connexion ignorée est signalée aux canaux d’alerte qui reçoivent les alertes d’utilisation, ou par courriel aux propriétaires de l’organisation s’il n’y en a aucun, au plus une fois par jour par connexion et par motif, avec la façon d’y remédier. La personne qui converse ne voit que la réponse.
• Limites. Au plus 10 connexions et 128 fonctions par requête, prises les plugiciels d’abord, puis les serveurs MCP, chacun par nom ; les autres sont indiquées comme ignorées avec le motif limit, qui n’est jamais signalé. Les outils d’une connexion sont offerts en entier ou pas du tout.

Ce sur quoi la déclaration s’appuierait : chaque connexion avec son status (ok, not_connected, expired, disabled, unreachable) et ses outils, chacun nommé comme le modèle le voit et marqué read ou write. Interrogé en direct avec une clé d’inférence ou de gestion ; un plugiciel qui ne peut pas être interrogé montre les outils de son manifeste enregistré, avec tools_source: "manifest". 30 requêtes par minute par clé.

Activés par défaut pour une clé

{"connected_tools": "read"}

Un robot conversationnel qui envoie de simples requêtes de clavardage peut utiliser vos connexions sans modifier son code : réglez connected_tools à read sur sa clé d’inférence (avec POST /v1/keys, PATCH /v1/keys/:hash, ou Outils connectés dans la page des clés API). Chaque requête faite avec cette clé reçoit alors la réponse qu’elle aurait eue en déclarant {"type": "autonomousrelay:connected"}, avec tout ce qui précède : les outils de lecture seulement, les connexions ignorées, l’en-tête de réponse et l’avis à votre organisation.

• Jamais d’écriture. Le réglage par défaut de la clé n’a pas de writes, et rien sur la clé ne peut en ajouter. Une écriture exige toujours la déclaration de la requête elle-même et une exécution dotée d’une politique d’approbation.
• La déclaration de la requête l’emporte. Une requête qui déclare elle-même autonomousrelay:connected garde ses include, exclude et writes ; ses fonctions et ses déclarations autonomousrelay:plugin ou autonomousrelay:mcp se combinent au réglage par défaut comme elles le feraient avec une déclaration.
• S’en passer, requête par requête. Envoyez l’en-tête de requête X-Autonomous-Relay-Connected-Tools: off, qu’on ajoute depuis n’importe quel SDK comme en-tête supplémentaire (toute autre valeur donne un 400). Les tours d’un agent hébergé (run_id) ne reçoivent jamais ce réglage : une définition d’agent déclare ses propres outils.
• Pas de mise en cache. Une réponse tirée de connexions en direct peut changer avec elles ; ces requêtes ne sont donc jamais servies par la mémoire cache des réponses, même sur une clé où elle est activée.
• Clés d’inférence seulement. Une clé de gestion n’appelle jamais de modèle ; connected_tools: "read" sur l’une d’elles donne donc un 400. Le réglage est désactivé par défaut.

Comment la boucle s’exécute

• Des tours. Chaque tour est une complétion entière, sans diffusion en continu. Les appels d’outils serveur d’un tour s’exécutent ensemble, leurs résultats repartent en messages tool, et le tour suivant commence. La boucle se termine quand le modèle répond sans appeler d’outil serveur — ou quand il appelle l’une de vos fonctions, qui vous est renvoyée comme d’habitude.
• Un plafond. max_tool_calls (de 1 à 30, 30 par défaut) limite les exécutions d’une requête. Au-delà, la dernière réponse est renvoyée avec native_finish_reason autonomousrelay:max_tool_calls ; un tour ultérieur que le fournisseur fait échouer renvoie la réponse précédente avec autonomousrelay:round_failed.
• Diffusion en continu. Avec stream: true, la boucle exécute toujours des tours entiers. La progression arrive en lignes de commentaire SSE (: autonomousrelay {"type": "tool.called", ...} — turn.completed, tool.called, tool.result), que les SDK ignorent, puis la réponse en fragments ordinaires.
• Usage. usage.server_tool_use compte les appels par outil. Les outils intégrés ne coûtent rien ; les jetons du modèle à chaque tour sont comptés comme d’habitude.
• Incompatible avec la mémoire cache des réponses et les lots : un outil s’exécute dans une requête en direct.
• Approbations. Une requête faite dans l’exécution d’un agent hébergé (run_id) dont la politique d’approbation couvre un outil s’arrête avant de l’exécuter : la réponse porte native_finish_reason autonomousrelay:approval_required et un objet autonomousrelay_approval, et l’exécution attend dans la page Agents.