Roster for MCP and custom AI agents
Add a reusable “who should act?” capability to any compatible AI agent.
Roster exposes participant resolution through a Streamable HTTP MCP server, giving compatible agents a standardized way to resolve approvers, owners, reviewers, groups, roles, service accounts, and delegated contacts.
Build the agent once. Keep organizational routing in Roster.
Last verified 07/13/2026
Agents need organizational context — not another hard-coded routing table
Agent frameworks are good at deciding which action to perform, which tool to call, which data to retrieve, and which workflow step comes next.
But production workflows also require a separate decision:
“Who should own, approve, review, receive, or handle the work?”
Teams often solve this with:
- Names embedded in prompts
- Static email addresses
- Environment variables
- YAML routing tables
- Slack-channel conventions
- Custom directory lookups
- Workflow-specific approver rules
Those approaches duplicate organizational logic across every agent. Roster centralizes the participant model and makes it callable through MCP.
How the integration works
MCP is an open standard for connecting AI applications to external tools, data, and workflows. Roster uses MCP as its primary agent-native integration surface.
AI agent
↓ MCP tool call
Roster /mcp
↓
Project and participant selection
↓
Directory membership and metadata
↓
Active delegations
↓
Resolved participant and users
↓
Agent continues its workflowUse resolve for open-ended questions, exact tools for exact checks
Authentication modes
Roster MCP supports both OAuth (recommended for interactive human users connecting through AI clients) and Roster API keys (recommended for service accounts, autonomous agents, CI pipelines, and non-interactive automation).
Roster API keys use the rst_ prefix, belong to a Roster identity, carry explicit scopes, can be inspected and revoked, and remain subject to the owner's Roster permissions. The default Roster MCP authentication mode can allow both OAuth and API-key access.
Resolve-only service-account scope — a narrowly scoped agent may only need:
mcp:resolve
mcp:resolve-requests:read
mcp:projects:read
mcp:participants:readDo not grant project, participant, label, delegation, or administrative write tools unless the agent is deliberately responsible for maintaining those resources.
Agent-framework pattern
Roster can be used with any framework or runtime capable of connecting to a compatible remote MCP server. Use a system or skill instruction such as:
Use Roster whenever the workflow needs to determine who should approve,
own, review, handle, receive, or be contacted for a task.
Call `resolve` for open-ended organizational-routing questions.
Use exact Roster tools for project, participant, membership, label,
delegation, and Resolve-history checks.
Treat Roster as the source of truth for current participant assignments
and delegations.
Never invent an owner or approver when Roster returns no authorized result.Tool descriptions and agent instructions are important because connecting an MCP server does not guarantee that an agent will select its tools for every relevant prompt.
Example agent workflow
An autonomous procurement agent has extracted a vendor request, classified the purchase, checked the contract amount, and identified the relevant business project. Before creating an approval request, it calls Roster.
“Who should approve this European software purchase for Atlas Operations at this amount?”
- The agent calls resolve with the classified business context:
resolve( query: "Who should approve this European software purchase for Atlas Operations at this amount?" ) - Roster evaluates the organizational context and returns the appropriate participant and active users.
- The agent sends the task through the organization's existing workflow or messaging system.
- After the decision, the agent continues its workflow.
Roster identifies the participant. Another system delivers, records, and enforces the approval.
MCP versus the REST API
Use MCP when the caller is an AI agent, natural-language tool selection is useful, the runtime already supports MCP, the agent needs multiple Roster tool families, or you want standardized tool discovery.
Use REST when the caller is a conventional application, the workflow is fully deterministic, you want direct endpoint-level control, your platform does not support MCP, or you are building an SDK or backend service.
Both surfaces use Roster's governed project, participant, directory, membership, and delegation model.