Skip to main content
Question

Enable MCP Server feature for API Tokens

  • June 1, 2026
  • 4 replies
  • 72 views
matias_sgherza

Hi Front community,

 

We successfully tested the MCP Server feature using OAuth and it works great. However, for our production use case we need this feature available for API Tokens as well.

Our scenario: we are building a centralized MCP server hosted on our own infrastructure that acts as a proxy to Front's MCP, consumed by multiple support agents through AI assistants (Claude Code). The server needs to authenticate against Front without per-user OAuth flows.

  

The challenge with OAuth:

  - The refresh token is tied to a specific user's identity

  - If that person leaves the team or the token is invalidated, the integration breaks

  - Managing token rotation in a server environment adds significant operational complexity

  

What we need:

API Tokens with MCP Server feature enabled, so we can authenticate our server-side MCP proxy with a stable, long-lived credential that isn't tied to a specific user's session.

This would be the ideal solution for teams building centralized MCP integrations on top of Front, which we believe is a common enterprise use case.

 

Has anyone else run into this? Is there a workaround available today?

  

Thanks,

Matias (MercadoLibre)

    4 replies

    alexis
    • alexis
    • Rookie
    • June 1, 2026

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

    alexis
    • alexis
    • Rookie
    • June 1, 2026

    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.

    martin_silva
    Forum|alt.badge.img+1

    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.

      matias_sgherza

       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.

        Terms & ConditionsAccessibility statement