← Reddit

How do I connect MCP that has a different linked email?

Reddit · xenoix · July 17, 2026
A user had their MCP connection to work JIRA forcibly disconnected due to an email matching requirement between their JIRA account and Claude subscription. Unable to obtain a work email account due to company cost-cutting measures, the user seeks a workaround to reconnect the MCP using their personal email instead.

Detailed Analysis

A Reddit post in r/ClaudeAI highlights a practical friction point in Anthropic's Model Context Protocol (MCP) implementation: the enforcement of matching email identities between a user's Claude account and the third-party service they're trying to connect to. The original poster describes a workflow where they used Claude to synthesize meeting notes with JIRA ticket data, connecting to their employer's JIRA instance via MCP. That integration was reportedly severed once Claude began requiring the linked JIRA account's email to match the email associated with the user's Claude subscription. Because the poster's employer will not provision a paid Claude seat under a company email (citing cost-cutting), but is otherwise fine with the employee using a personal Claude account for work purposes, the user is now caught in an identity-verification gap with no clear workaround.

This issue points to a broader tension in how AI assistants authenticate and authorize access to external tools and data sources. MCP was designed by Anthropic as an open standard to let Claude (and other AI systems) securely connect to databases, project management tools, file systems, and SaaS platforms without bespoke integrations for each service. Security and identity binding are central to that design — MCP connections often rely on OAuth flows or API tokens tied to a specific account, and requiring email-match verification is a reasonable safeguard against unauthorized data access or account confusion. However, this same safeguard becomes a liability in real-world "bring your own AI" scenarios, where employees use personal AI subscriptions for work tasks because their employer hasn't (or won't) formally provision or license the tool. This is an increasingly common pattern as generative AI adoption in workplaces outpaces IT and procurement processes.

The friction reflects a larger unresolved problem in enterprise AI adoption: the mismatch between individual, ad hoc AI usage and organizational identity/access management systems. Companies frequently lag in setting up official seats, SSO integrations, or approved tool lists for AI products, while employees who find genuine productivity value in tools like Claude improvise with personal accounts. This creates exactly the kind of authentication deadlock described here — the employee has legitimate business need and employer tacit approval, but no clean technical path to link a personally-owned AI identity with a company-owned SaaS account without triggering security controls meant to prevent exactly that kind of cross-account access.

Anthropic and other AI vendors will likely face growing pressure to address this gap, whether through more flexible enterprise MCP configurations, delegated access grants (where an admin can authorize specific external accounts for named individual users regardless of email match), or clearer guidance on hybrid personal/enterprise use cases. Until then, community threads like this one on r/ClaudeAI serve as an informal support channel where users trade workarounds — a signal that self-service documentation and enterprise tooling haven't yet caught up to how people are actually deploying AI assistants inside resource-constrained organizations. This also underscores why "shadow AI" — unauthorized or unofficial AI tool usage inside companies — remains a persistent governance challenge as adoption spreads faster than IT policy.

Read original article →