Roster pour Cursor
Donnez à Cursor un contexte de responsabilité en direct autour du code.
Connectez Cursor à Roster via MCP pour qu'il puisse déterminer qui est responsable d'un service, qui doit effectuer la revue ou approuver un changement, et qui doit prendre en charge une escalade liée au travail d'ingénierie.
Cursor comprend le code. Roster détermine qui doit intervenir.
Dernière vérification : 14 juillet 2026
Le contexte du dépôt ne répond pas à toutes les questions de responsabilité
Cursor peut inspecter un codebase, modifier des fichiers, exécuter des commandes et utiliser le contexte du projet pour réaliser des tâches d'ingénierie.
Mais la personne actuellement responsable n'est pas toujours définie dans le dépôt :
“Qui est responsable de ce service aujourd'hui ?”
“Qui doit réviser cette modification de l'authentification ?”
“Qui approuve le déploiement en production ?”
“Qui reçoit cette escalade de sécurité ?”
“Qui remplace le responsable de la mise en production ?”
CODEOWNERS, l'historique du dépôt et la documentation fournissent des signaux utiles, mais ne reflètent pas toujours les rôles métier, appartenances aux projets, régions, règles d'approbation, disponibilités ou délégations temporaires. Roster rend ce contexte organisationnel disponible via l'interface MCP de Cursor.
Comment Roster s'intègre à Cursor
Cursor prend en charge les serveurs MCP distants Streamable HTTP. Roster se branche comme l'un de ces serveurs via la configuration projet ou utilisateur.
Cursor Agent
↓
Connexion MCP distante
↓
Serveur MCP Roster
↓
Responsabilités projet + service
↓
Utilisateurs, groupes, rôles, appartenances et délégations
↓
Responsable, réviseur, approbateur ou contact d'escalade identifiéCe que Cursor peut identifier autour du code
Connecter Roster à Cursor
Ajoutez Roster comme serveur MCP distant dans Cursor. Utilisez une configuration projet lorsque la connexion doit accompagner un dépôt précis, ou une configuration utilisateur lorsque la même connexion doit être disponible entre projets.
La documentation MCP actuelle de Cursor prend en charge les serveurs distants Streamable HTTP, la configuration projet .cursor/mcp.json, la configuration globale ~/.cursor/mcp.json, les en-têtes et l'interpolation de variables d'environnement. Exemple de configuration projet :
{
"mcpServers": {
"roster": {
"url": "https://roster.example.com/mcp",
"headers": {
"Authorization": "Bearer ${env:ROSTER_API_KEY}"
}
}
}
}Définissez ROSTER_API_KEY dans l'environnement utilisé pour lancer Cursor. Cursor documente la syntaxe d'interpolation ${env:NAME} pour les en-têtes de serveurs distants. Les clés API Roster sont envoyées comme jetons Bearer.
La clé API requiert mcp:resolve pour appeler l'outil resolve de Roster. Ajoutez d'autres portées de lecture mcp:* uniquement si Cursor doit utiliser les outils de consultation correspondants.
Après l'enregistrement de la configuration :
- Ouvrez Cursor Settings → Tools & MCP.
- Vérifiez que le serveur Roster se connecte et que ses outils sont disponibles.
- Activez uniquement les outils nécessaires au projet.
- Testez avec un prompt délimité tel que : « Utilise Roster pour identifier le responsable du service d'identité Atlas. »
Portées pour une automatisation limitée à resolve
Pour les workflows limités à resolve, utilisez des portées restreintes. L'accès effectif reste contraint par les autorisations Roster de l'identité active et les règles de ressources cibles.
mcp:resolve
mcp:resolve-requests:read
mcp:projects:read
mcp:participants:readAjouter une règle Cursor pour Roster
Rendre le serveur MCP disponible ne garantit pas que l'agent l'appellera à chaque fois qu'un contexte organisationnel est requis. Ajoutez une règle projet ou équipe qui définit quand Roster est la source de référence.
# Responsabilités et routage organisationnels
Utilise le serveur MCP Roster pour les questions actuelles de responsabilité,
d'approbation, de revue, d'escalade, de participants, d'appartenance et de délégation.
Ne déduis pas les responsables ou approbateurs actuels depuis l'historique du
dépôt, CODEOWNERS, la documentation ou la mémoire du modèle lorsque Roster est disponible.
Pour les questions ouvertes, appelle `resolve`. Retourne explicitement les absences
de résultat, les réponses hors périmètre et les erreurs d'autorisation. N'invente jamais de responsable.Exemple : identifier l'approbateur d'un déploiement
Un développeur demande à Cursor :
“Révise cette livraison et détermine qui doit approuver le déploiement en production d'Atlas.”
- Cursor analyse le dépôt et les changements de la livraison.
- L'agent détermine qu'une approbation organisationnelle est requise.
- Cursor appelle Roster :
resolve( query: "Qui doit approuver le déploiement en production d'Atlas ?" ) - Roster évalue le projet Atlas, le participant d'approbation de mise en production, les libellés et métadonnées pertinents, l'appartenance d'annuaire, le statut actif et les délégations.
- Cursor retourne l'approbateur sélectionné ou un état d'exception explicite.
Cursor ou un système connecté peut ensuite créer une demande de revue, un commentaire de pull request, un ticket ou une tâche d'approbation.
Roster complète les systèmes de responsabilité d'ingénierie
Roster ne remplace pas CODEOWNERS, les équipes GitHub ou GitLab, Backstage, les catalogues de services, les plateformes de gestion d'incidents ni les outils de gestion de projet. Ces systèmes peuvent fournir une responsabilité statique ou propre à une plateforme.
Roster ajoute une résolution à l'exécution lorsque la réponse dépend du projet, de l'annuaire, du rôle métier, de la région, d'un seuil, du statut actif, d'une délégation ou d'une responsabilité interfonctionnelle.
- Contexte projet
- Appartenance d'annuaire
- Rôle métier
- Région
- Seuil d'approbation
- Statut actif
- Délégation
- Responsabilité interfonctionnelle