Enable MCP Server feature for API Tokens

I need this for a personal agent on a sandbox node.

As a super super hacky workaround, I’ve built a stdio mcp server that sits in front of the hosted mcp server. It keeps an oauth token refreshed and injects that. then authed on my own machine to capture token and then slapped it in.

Please fix.

Hi Matías,

Thanks for sharing this — you're describing a real gap and you're not alone in hitting it.

To explain why this gap exists: OAuth was designed for the personal use case, a teammate connecting their own AI assistant to their own Front inbox. In that model, the token being tied to a specific person's identity is a feature, not a bug. It means the AI acts as that person, respects their permissions, and stays scoped to what they can see and do. Your scenario is fundamentally different, you're building a system that acts on behalf of multiple agents, and for that, OAuth's per-user model becomes an operational liability exactly as you described.
The challenge with just enabling API tokens for MCP isn't purely technical. API tokens today don't have a granular scope model, enabling them for MCP would give broad access with limited guardrails, which we want to get right before opening that up. What you actually need is closer to a service account concept: a stable, non-human identity with configurable scopes that can authenticate server-side without being tied to a person.

The workaround today is creating a dedicated Front seat specifically for the integration — a "service user" that isn't tied to a real person. It's not clean but it's stable and won't break if someone leaves the team.

API token support for MCP is something we're aware of and thinking about. We can't share a timeline yet but feedback like yours helps us prioritize and which we will do. If others are hitting the same thing, would love to hear about it in this thread.

Thanks again for the detailed write-up, Matias.

 Hi Martin, thanks for the thorough explanation — the distinction between the personal

  OAuth use case and the server-side proxy scenario is exactly right, and

  "service account with configurable scopes" is precisely what we'd need.

  We'll go with the dedicated seat workaround for now. It's not ideal

  operationally but it solves the stability problem.

  A couple of things that would help us as you think through the API token /

  service account direction:

  Since we're moving forward with OAuth for now, do you

  have documentation or guidance on refresh token management for server-side / 

  non-interactive scenarios?

  Specifically, we need to understand:

  - Token lifetime — how long do access tokens and refresh tokens last?

  - Refresh flow — is there a standard OAuth refresh_token grant we can call to

  rotate the access token programmatically?

  - Revocation / expiry behavior — under what conditions does a refresh token

  get invalidated (user action, inactivity, re-auth required)?

  - Best practices for storing and rotating tokens in a headless server

  environment

  The dedicated seat workaround works for us as a starting point, but we want to

  make sure the token management on our end is solid before going to

  production.

  Thanks again, Matias.