Built for engineering teams

Deploy MCP servers fast, with governance built in

Host MCP servers once, put your identity provider in front, and scope access per tool. Every client your team already uses connects to the same endpoint, with nothing to set up per machine.

Trusted by

Deploy once, connect everyone

Deploy a server once and every engineer connects to the same endpoint from the client they already use. Access follows your directory groups, credentials stay in the gateway, and every call is logged.

Claude Code, Cursor, VS Code, Codex, ChatGPT, and any other MCP client connect to the same endpoint. Local setups keep working.

Install instructions for one endpoint, tabbed across Claude Code, Claude.ai, Cursor, VSCode, Codex, and ChatGPT, with the command and the server URL

Mint hosts open-source and custom servers in sandboxed containers, with auth and permissions set when you deploy.

Add a tool to a Virtual MCP and everyone with access gets it on their next connection. No client reconfiguration.

One Virtual MCP per role, granted to the group behind it, with each person authenticating as themselves. Group changes in your directory come through SCIM.

Requests, tokens, and spend split by user, session, model, and tool, with the full log underneath when something fails.

Scalable infrastructure

Hosting, auth, and scoping in one package

Mint hosts the servers, handles OAuth on both sides and token refresh, scopes access per tool, and keeps the audit log. As transports and client behaviour change, we update the gateway.

Hosting and runtime
OAuth, both directions
Token refresh and rotation
Tool scoping and policy
Audit trail and export
Every client's quirks

Coding agents on laptops are logged too

Hooks for Claude Code and Cursor report what an agent did on a laptop, so calls that never touch a server land in the same log. Nobody changes editors or workflow.

Run your own middleware on every call

Middleware hooks run your code on every request to a server, versioned, pre or post, in enforce or dry-run mode, so a rule specific to your systems does not need a fork. Screening and DLP are on the security page

Middleware attached to a server, each entry with its version, pre or post phase, and enforce or dry-run mode

Credentials brokered securely

Clients authenticate to the endpoint over OAuth, delegating to your identity provider. The gateway then reaches each connector its own way, per-user OAuth or a service account, and holds the refresh. The two layers stay independent, so changing a downstream credential never touches a client.

Mustafa Furniturewala

“We needed to be able to host our own MCPs, and we didn't want a different solution for that, because it needs to be done in a secure way as part of the gateway setup. The other thing that's important is setup time. I didn't want someone to have to add 60 different MCPs.”

Coursera

Mustafa Furniturewala

CTO @ Coursera

Deploy your first Virtual MCP

Deploy a server, grant a team access, and see the first calls in the log.

Frequently asked questions

Yes. Each role gets its own Virtual MCP with its own set of servers, and within each server you switch individual tools on or off. Analysts can get read access to the warehouse while engineers get read and write, from the same underlying server.

Yes. SSO connects to Okta, Azure AD, or Google Workspace, and SCIM syncs your groups. Grant a Virtual MCP to a group, and access follows group membership: add someone to the group in your directory and they have it, remove them and they don't.

Claude Code, Claude.ai, Cursor, VS Code, Codex, ChatGPT, Copilot, and any other client that speaks MCP. Each one connects to the same endpoint, and the permissions and log are the same whichever client a person uses.

Clients authenticate to the gateway over OAuth, delegated to your identity provider. Downstream, the gateway reaches each server the way it needs: per-user OAuth, a service account, or an API key it holds for you, with token refresh handled. Changing a downstream credential never touches a client.

Point the gateway at the API's documentation and describe what the server should expose. It writes the connector, hosts it, and puts auth in front. Teams use this to cover endpoints an official server never exposed.

Open the call in the log. It holds the arguments, the status, and whether it ran as a person, an agent, or a service account, so you do not need to reproduce it or ask for someone's config file.

Mint hosts the servers, handles auth on both sides, scopes access per tool, and keeps the audit log, and we keep the gateway current as auth patterns, transports, and client behaviour change. Teams that priced building this themselves usually found it was two or three engineers.