LogRocket

Debugging with real session evidence instead of guesses. LogRocket describes it as letting Cursor, Claude Code, Codex and other clients query the LogRocket API about sessions, metrics and issues, so an agent can pull context about how your app behaved, understand how users interact with a feature, and investigate a specific user or account's sessions.

Nothing in the listed tool set writes. All seven tools read or build queries: listing organizations and projects, finding sessions and issues, watching sessions, and building a metric. LogRocket frames the server as querying the LogRocket API for information, and publishes no write or delete tool in this surface.

In practice yes, and two tools exist for it. list_organizations and list_projects enumerate what your account can reach, which is how an agent resolves the right project before calling find_sessions or find_issues. The use_logrocket tool is the documented entry point for orienting an agent in the workflow.

LogRocket publishes several. Its examples include asking an agent to watch a specific user's sessions to find a checkout root cause, to explain how a feature is currently used before you change it, to triage the past week's new issues by root cause, and to check whether last week's commits introduced regressions.

No, it uses OAuth. We confirmed the server issues an HTTP 401 with a Bearer challenge carrying realm OAuth, and publishes RFC 9728 metadata naming itself as the authorization server. There is no API key to paste into a client config, and the sign-in happens in the browser.

No. The connector reaches what your LogRocket account reaches, and list_organizations and list_projects exist precisely to enumerate that scope. LogRocket publishes no documented mechanism for the MCP server to widen access beyond the authenticated user's own organizations and projects, and the server advertises no OAuth scopes that would narrow it either.