Roster pour MCP et agents IA personnalisés

Ajoutez une capacité réutilisable « qui doit agir ? » à tout agent IA compatible.

Roster expose la résolution de participants via un serveur MCP Streamable HTTP, offrant aux agents compatibles un moyen standardisé de résoudre approbateurs, responsables, réviseurs, groupes, rôles, comptes de service et contacts délégués.

Construisez l'agent une fois. Gardez le routage organisationnel dans Roster.

Connecter un client MCP Explorer les outils MCP

Dernière vérification : 13 juillet 2026

Les agents ont besoin de contexte organisationnel — pas d'une nouvelle table de routage codée en dur

Les frameworks d'agents sont bons pour décider quelle action exécuter, quel outil appeler, quelles données récupérer et quelle étape de workflow vient ensuite.

Mais les workflows en production exigent aussi une décision distincte :

“Qui doit posséder, approuver, réviser, recevoir ou prendre en charge le travail ?”

Les équipes résolvent souvent cela avec :

Des noms intégrés dans les prompts
Des adresses email statiques
Des variables d'environnement
Des tables de routage YAML
Des conventions de canaux Slack
Des recherches d'annuaire personnalisées
Des règles d'approbation spécifiques au workflow

Ces approches dupliquent la logique organisationnelle dans chaque agent. Roster centralise le modèle de participants et le rend appelable via MCP.

Comment l'intégration fonctionne

MCP est un standard ouvert pour connecter les applications IA à des outils, données et workflows externes. Roster utilise MCP comme interface d'intégration principale conçue pour les agents.

Agent IA
   ↓ Appel d'outil MCP
Roster /mcp
   ↓
Sélection de projet et participant
   ↓
Appartenance et métadonnées d'annuaire
   ↓
Délégations actives
   ↓
Participant et utilisateurs résolus
   ↓
L'agent poursuit son workflow

Utilisez resolve pour les questions ouvertes, outils exacts pour vérifications exactes

resolve

Accepte une requête en langage naturel, un ID de projet optionnel et un mode test ou live optionnel. Roster extrait les références projet, libellés, rôles et contraintes pertinents, puis identifie les utilisateurs associés, les membres de groupes actifs et les délégations actives.

“Qui doit approuver le renouvellement fournisseur Atlas ?”

Projets et participants

Listez les projets accessibles à l'identité agissante. Listez ou inspectez les participants d'un projet.

“Liste les participants du projet Atlas.”

Vérifications d'appartenance

Vérifiez de manière déterministe si un utilisateur est membre d'un participant.

“Vérifie si cet utilisateur est membre du participant Release Approver.”

Délégations

Listez les délégations actives qui affectent un participant en ce moment.

“Liste les délégations actives pour ce participant.”

Enregistrements d'annuaire

Consultez les enregistrements d'annuaire matérialisés associés aux participants.

Historique des requêtes Resolve

Récupérez les requêtes Resolve récentes pour audit, contexte ou observabilité.

Modes d'authentification

Le MCP Roster prend en charge à la fois OAuth (recommandé pour les utilisateurs humains interactifs via clients IA) et les clés API Roster (recommandées pour les comptes de service, agents autonomes, pipelines CI et automatisation non interactive).

Les clés API Roster utilisent le préfixe rst_, appartiennent à une identité Roster, portent des autorisations explicites, peuvent être inspectées et révoquées, et restent soumises aux permissions Roster du propriétaire. Le mode d'authentification MCP Roster par défaut peut autoriser à la fois OAuth et clé API.

Scope compte de service resolve-only — un agent à portée étroite peut n'avoir besoin que de :

mcp:resolve
mcp:resolve-requests:read
mcp:projects:read
mcp:participants:read

N'accordez pas d'outils d'écriture projets, participants, libellés, délégations ou administratifs, sauf si l'agent est délibérément responsable de la maintenance de ces ressources.

Modèle d'intégration avec un framework d'agents

Roster peut être utilisé avec tout framework ou runtime capable de se connecter à un serveur MCP distant compatible. Utilisez une instruction système ou de compétence telle que :

Utilise Roster chaque fois que le workflow doit déterminer qui doit
approuver, posséder, réviser, prendre en charge, recevoir ou être contacté
pour une tâche.

Appelle `resolve` pour les questions ouvertes de routage organisationnel.

Utilise les outils Roster exacts pour les vérifications de projet,
participant, appartenance, libellé, délégation et historique Resolve.

Considère Roster comme la source de référence pour les affectations actuelles
de participants et les délégations.

N'invente jamais un propriétaire ou approbateur lorsque Roster ne renvoie
aucun résultat autorisé.

Les descriptions d'outils et les instructions d'agent sont importantes, car connecter un serveur MCP ne garantit pas qu'un agent sélectionnera ses outils pour chaque prompt pertinent.

Exemple de workflow d'agent

Un agent achats autonome a extrait une demande fournisseur, classé l'achat, vérifié le montant du contrat et identifié le projet métier pertinent. Avant de créer une demande d'approbation, il appelle Roster.

“Qui doit approuver cet achat logiciel européen pour Atlas Operations à ce montant ?”

L'agent appelle resolve avec le contexte métier classé :

resolve(
  query:
  "Qui doit approuver cet achat logiciel européen
   pour Atlas Operations à ce montant ?"
)

Roster évalue le contexte organisationnel et renvoie le participant approprié et les utilisateurs actifs.
L'agent envoie la tâche via le système de workflow ou de messagerie existant de l'organisation.
Après la décision, l'agent poursuit son workflow.

Roster identifie le participant. Un autre système livre, enregistre et applique l'approbation.

MCP par rapport à l'API REST

Utilisez MCP lorsque l'appelant est un agent IA, que la sélection d'outil en langage naturel est utile, que le runtime prend déjà en charge MCP, que l'agent a besoin de plusieurs familles d'outils Roster, ou que vous voulez une découverte d'outils standardisée.

Utilisez REST lorsque l'appelant est une application conventionnelle, que le workflow est totalement déterministe, que vous voulez un contrôle direct au niveau des endpoints, que votre plateforme ne prend pas en charge MCP, ou que vous construisez un SDK ou service backend.

Les deux surfaces utilisent le modèle gouverné de projets, participants, annuaire, appartenance et délégation de Roster.

Conception sécurité

Attribution d'identité

Chaque agent ou compte de service doit agir sous sa propre identité Roster.

Moindre privilège

N'accordez que les autorisations requis par le workflow.

Périmètres de projet

Les autorisations MCP ne contournent pas l'autorisation au niveau projet et ressource.

Contexte contrôlé

N'envoyez que le contexte métier nécessaire à la décision de routage.

Gestion explicite des échecs

Traitez l'absence de résultat, l'ambiguïté, l'échec d'autorisation et l'échec fournisseur comme des états du workflow, pas comme des occasions pour l'agent de deviner.

Requêtes auditables

Utilisez l'historique Resolve et les capacités d'audit disponibles pour inspecter comment les décisions organisationnelles ont été prises.

Séparation du passage de relais à un humain

Roster identifie le participant. Un autre système doit livrer, enregistrer et appliquer l'approbation ou la tâche.

Questions fréquentes

Non. Roster est une plateforme de résolution de participants et un serveur MCP que les agents et frameworks peuvent appeler.

Donnez à chaque agent la même capacité organisationnelle permettant de déterminer qui doit agir

Utilisez une seule surface gouvernée de résolution de participants à travers clients d'agents, agents internes, plateformes d'automatisation et workflows CI.

Connecter un client MCP Explorer les outils MCP Explorer toutes les intégrations