← Back to directory
A

Access MCP Server

Official
Manage internal access through MCP.
GitHub source repository ↗
★ 475 Stars Category · Other Very popular Source revision 9feab299f19c
63FMRS · C
Reliability
9/20
Security and permissions
15/20
Maintenance
11/20
Documentation
16/20
Setup experience
12/20

The source identifies this as an MCP server embedded in Discord's Access project. It exposes permission discovery and request-submission capabilities over Streamable HTTP and is disabled by default. The source does not provide the complete names of all 21 tools or a client installation configuration example.

Read the FMRS scoring method →

Access is Discord's centralized portal for employees to discover, request, and manage access to the internal systems needed for their work. When its optional MCP server is enabled, compatible clients can browse groups, roles, apps, users, tags, audit entries, memberships, and requests, and submit access requests on behalf of the authenticated user.

Tools

create_access_request
Requests group membership or ownership for the current user.
create_role_request
Allows a role owner to request that a role be granted access to a group.
create_group_request
Requests creation of a new group, role, or application group.

Setup

Set ENABLE_MCP=true in the production configuration for an Access deployment, then connect the MCP client to https://<your-access-deployment>/mcp. MCP uses Streamable HTTP. Configure either Cloudflare Access or OIDC authentication; development and test environments can use the development provider based on CURRENT_OKTA_USER_EMAIL. The source does not provide a client configuration example.

Fit and risk

Best for

  • Organizations that need centralized visibility into Okta-related internal access.
  • Teams that want MCP clients to assist with permission discovery and pending request submission.
  • Operators able to configure Cloudflare Access or OIDC for an Access deployment.

Not for

  • Workflows requiring MCP to approve or reject requests.
  • Workflows requiring direct MCP mutation of groups, roles, or apps.
  • Users without an Access deployment, Okta data, or a supported authentication setup.

Required permissions

  • Access to the Okta API is required; development setup calls for Group Admin and Application Admin roles plus group-management permissions.
  • Production deployments require Cloudflare Access or OIDC authentication.
  • MCP tools require read_all or create_requests scopes, while Access authorization rules still apply to each operation.

Risks and side effects

  • A misconfigured Okta API token may grant excessive group or application administration privileges.
  • Tokens without an explicit scope receive read_all and create_requests by default; operators can configure read-only or fail-closed behavior.
  • Enabling MCP allows authenticated clients to read access data and submit pending requests.
  • Incorrect proxy Host or OIDC callback configuration can create redirect-URI risks; the source recommends ALLOWED_HOSTS and OIDC_OVERWRITE_REDIRECT_URI.

Troubleshooting

  1. Verify ENABLE_MCP=true and use the deployed /mcp POST endpoint.
  2. Ensure Cloudflare Access and OIDC are not both configured for MCP; they are mutually exclusive.
  3. For OIDC, check OIDC_SERVER_METADATA_URL, OIDC_MCP_AUDIENCE, and token signature, iss, exp, and aud validation.
  4. For Cloudflare Access, check the team domain, application audience, and token source.
  5. If a tool is denied, check token scopes, user identity, and the corresponding REST authorization rule.
  6. For local development, verify ENV is development or test and set CURRENT_OKTA_USER_EMAIL.

Use cases

Browse available groups, roles, apps, and access requests.
Submit access, role, or group-creation requests for the authenticated user.
Distinguish MCP-originated mutations from web activity in audit logs.

Supported clients

Claude CodeFull support
Claude.aiFull support
CursorFull support
ZedFull support
Self-hosted modelsPartial support