Roster for Cursor

Give Cursor live ownership context around the code.

Connect Cursor to Roster over MCP so its agent can resolve who owns, reviews, approves, handles, or receives an escalation for engineering work.

Cursor understands the repository. Roster resolves who should act around it.

Connect Roster to Cursor Read the Roster MCP documentation

Last verified 07/14/2026

Repository context cannot answer every ownership question

Cursor can inspect a codebase, edit files, run commands, and use project context while completing engineering tasks.

But the current accountable person may not be encoded in the repository:

“Who owns this service today?”

“Who should review this authentication change?”

“Who approves the production deployment?”

“Who receives this security escalation?”

“Who is covering for the release owner?”

CODEOWNERS, repository history, and documentation may provide useful signals, but they do not always reflect business roles, project membership, geography, approval policy, active status, or temporary delegation. Roster makes that organizational context available through Cursor's MCP interface.

How Roster fits into Cursor

Cursor supports Streamable HTTP remote MCP servers. Roster plugs in as one of those servers through project- or user-level configuration.

Cursor Agent
        ↓
Remote MCP connection
        ↓
Roster MCP server
        ↓
Project + service ownership
        ↓
Directory users, groups, roles, memberships, and delegations
        ↓
Resolved owner, reviewer, approver, or escalation contact

What Cursor can resolve around the code

Component or service ownership

Look up the current owner of a service or component from the Roster participant model.

“Use Roster to find who owns the identity service.”

Review responsibility

Route review requests to the participant responsible for a specific system or risk area.

“Who should review this change to authentication logic?”

Deployment approval

Resolve the approver for a production release based on project, environment, and delegation.

“Who should approve the Atlas production release?”

Security escalation

Route dependency vulnerabilities and security findings to the right owner.

“Which participant should receive this dependency vulnerability escalation?”

Cross-functional review

Pull in security, procurement, privacy, or legal reviewers when a code change requires them.

“Who should review this new third-party library from security and procurement?”

Delegated coverage

Return the active delegate when the normal owner is unavailable.

“Who is covering for the platform release owner?”

Connect Roster to Cursor

Add Roster as a remote MCP server in Cursor. Use a project configuration when access should travel with a specific repository, or a user configuration when the same connection should be available across projects.

Cursor's current MCP documentation supports Streamable HTTP remote servers, project-level .cursor/mcp.json, global ~/.cursor/mcp.json, headers, and environment-variable interpolation. Example project configuration:

{
  "mcpServers": {
    "roster": {
      "url": "https://roster.example.com/mcp",
      "headers": {
        "Authorization": "Bearer ${env:ROSTER_API_KEY}"
      }
    }
  }
}

Set ROSTER_API_KEY in the environment used to launch Cursor. Cursor documents the ${env:NAME} interpolation syntax for remote-server headers. Roster API keys are sent as bearer tokens.

The API key requires mcp:resolve to call Roster's resolve tool. Add other mcp:* read scopes only if Cursor must use the corresponding exact lookup tools.

After saving the configuration:

Open Cursor Settings → Tools & MCP.
Confirm that the Roster server connects and its tools are available.
Enable only the tools required for the project.
Test with a scoped prompt such as: "Use Roster to find who owns the Atlas identity service."

Resolve-only automation scope

For resolve-only workflows, use narrow scopes. Effective access remains constrained by the acting Roster identity's permissions and target-resource rules.

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

Add a Cursor rule for Roster

Making the MCP server available does not ensure the agent will call it whenever organizational context is required. Add a project or team rule that defines when Roster is the source of truth.

# Organizational ownership and routing

Use the Roster MCP server for current ownership, approval, review,
escalation, participant, membership, and delegation questions.

Do not infer current owners or approvers from repository history,
CODEOWNERS, documentation, or model memory when Roster is available.

For open-ended questions, call `resolve`. Return no-result,
out-of-scope, and authorization failures explicitly. Never invent
an assignee.

Example: resolve a deployment approver

A developer asks Cursor:

“Review this release and determine who must approve the Atlas production deployment.”

Cursor reviews the repository and release changes.
The agent determines that organizational approval is required.

Cursor calls Roster:

resolve(
  query: "Who should approve the Atlas production deployment?"
)

Roster evaluates the Atlas project, release-approval participant, relevant labels and metadata, directory membership, active status, and delegations.
Cursor returns the selected approver or an explicit exception state.

Cursor or a connected system can then create a review request, pull-request comment, ticket, or approval task.

Roster complements engineering ownership systems

Roster does not need to replace CODEOWNERS, GitHub or GitLab teams, Backstage, service catalogs, incident-management platforms, or project-management systems. Those systems can provide static or platform-specific ownership.

Roster adds runtime resolution when the answer depends on current project context, directory membership, business role, geography, approval threshold, active status, delegation, or cross-functional responsibility.

Project context
Directory membership
Business role
Geography
Approval threshold
Active status
Delegation
Cross-functional responsibility

Security and governance

Project versus user configuration

Use project-level MCP configuration only when the connection belongs with the repository. Review shared configuration before committing it.

No secrets in source control

Keep Roster tokens in environment variables or supported credential storage, never directly in .cursor/mcp.json.

Least privilege

Grant mcp:resolve for participant resolution, plus only the exact mcp:* read scopes required by the engineering workflow.

Controlled tool access

Enable only the tools the Cursor agent needs for the project.

Explicit failure handling

Treat no-result, out-of-scope, authentication, and authorization failures as outcomes. Do not let the agent substitute a guess.

Auditable requests

Use Resolve Requests to inspect the recorded resolution status, actor, project, query, and result counts visible to the acting identity.

Frequently asked questions

Both use the Roster MCP server and the same participant-resolution model. Cursor and Codex have different configuration, authentication, rules, and team-distribution mechanisms.

Connect Cursor to current organizational ownership

Let Cursor work with the code while Roster resolves the people, groups, roles, and delegates responsible for what happens next.

Connect Roster to Cursor Read the Roster MCP documentation Explore all integrations