Cursor
Use the exact OneMCP URL supplied by the gateway dashboard, on https://mcpgateway.quilr.ai or your assigned hostname under quilrai.com. Never enter a literal wildcard hostname. Confirm the administrator checklist before rollout.
Documentation checked: 15 October 2026. Validate this setup against your client version and deployment; the guide does not represent a completed live connection test.
Add the server
Cursor supports remote Streamable HTTP and OAuth. Use .cursor/mcp.json for a project or ~/.cursor/mcp.json for the user. Merge this entry into any existing configuration. Cursor MCP reference.
{
"mcpServers": {
"quilr-onemcp": {
"url": "https://mcpgateway.quilr.ai/quilrone/mcp"
}
}
}
If the dashboard gives you a tenant-scoped endpoint, use https://mcpgateway.quilr.ai/quilrone/<quilr-tenant-id>/mcp instead, replacing the placeholder. For one server use its direct gateway URL. Keep the endpoint and OAuth issuer from the same deployment.
Open Customize, enable the server, and complete the offered OAuth sign-in. Review the available tools and approvals before using them. Cursor server management.
For Quilr OneMCP, begin with the URL-only configuration so the client discovers registration. Do not add an auth.CLIENT_SECRET or copy an upstream provider's credentials into this file. Gateway DCR returns a public client without a secret. See authentication for current protocol and token-lifecycle limitations.
Administrator distribution and restrictions
Cursor distinguishes distribution from policy. Team servers are managed in Dashboard > Plugins & MCPs; existing team servers can be linked to a team marketplace. Enterprise MCP allowlists are configured in Team Settings > MCP Configuration. URL entries approve remote endpoints; allowing one does not install it. Cursor enterprise controls.
For a Quilr rollout:
- Distribute the exact approved URL, never an administrator's token or personal connection.
- Set the enterprise URL rule to match that endpoint. Include the intended tenant/backend path rather than approving unrelated deployments.
- Allow the actual Cursor runtime under Quilr Allowed Agents and configure the permitted user groups and tools.
- Have users authenticate with their own company accounts and connect required upstream services.
- Validate IDE, CLI, and cloud runtimes separately if the organization enables them. Endpoint distribution alone does not establish credentials or network reachability in each runtime.
Tool auto-run policy controls confirmation behavior in Cursor. Gateway authorization remains responsible for whether the user may access a backend or invoke a tool. Review both layers for write-capable operations.
Direct API-token option
For an eligible non-OAuth backend only, an administrator can issue a gateway API token and require both Authorization and mcpuser. Use environment interpolation rather than committing the secret. Cursor supports ${env:NAME} in headers. Cursor configuration interpolation.
{
"mcpServers": {
"quilr-direct": {
"url": "https://mcpgateway.quilr.ai/<backend-id>/mcp",
"headers": {
"Authorization": "Bearer ${env:QUILR_MCP_TOKEN}",
"mcpuser": "employee@customer.example"
}
}
}
}
Make the variable available to the process launching Cursor through your approved secret-management mechanism. Replace the backend and employee placeholders. The token must be issued for that backend and the matching client identity. This configuration is not valid for OneMCP. The supplied email is trusted caller attribution rather than proof of employee SSO.
Validate and troubleshoot
Run the shared validation procedure: list connectors, discover a read-only tool, invoke it, and verify employee attribution in gateway logs. Test a second user's visibility and restart/reconnect behavior.
Removing the local entry stops that client configuration. Revoke the relevant gateway credential or connection separately when access must end.