Thanks for support..
Release: "Sentinel-IR-MCP v0.2.2 on GitLab" (https://gitlab.com/jakubrojicek11/sentinel-ir-mcp/-/tree/v0.2.2?ref_type=tags)
Package: "sentinel-ir-mcp@0.2.2 on npm" (https://www.npmjs.com/package/sentinel-ir-mcp/v/0.2.2)
During my zero-credentials test on Windows, I stumbled upon a fascinating asymmetrical behavior in Cursor's security model regarding how MCP servers are spawned:
• The Project Gate (.cursor/mcp.json): If you are not logged into a Cursor/Anysphere account, project-level MCP configurations are strictly dead on arrival. Cursor detects them, but the state transition immediately drops to disconnected (enabledTotal: 0). It seems Cursor treats unapproved workspace configs as a massive RCE vector (and rightfully so—imagine opening a malicious git repo that auto-spawns malware via a hidden MCP config). The UI toggles to approve these are locked behind the onboarding/login screen.
• The Deep-link Bypass (cursor://...): On the flip side, if you trigger a user-level installation via the README deep-link, it connects and spawns the 3 tools perfectly even without being logged in. Because this requires an explicit external user interaction (clicking a link and confirming an OS-level prompt), Cursor trusts it as a global user intent and bypasses the login requirement entirely.
TL;DR for MCP Developers: If your enterprise users are running offline/no-login environments, project-level configs won't save them. Stick to global user configs via deep-links!
