Skip to main content

Gateway customization

MintMCP's gateway is a curated, branded interface for your organization's AI tools—not just a proxy. You control what goes in your registry, how connectors are packaged for teams, and how they appear to users.

Custom registry​

The MCP store is your organization's internal registry of approved AI tools. By default it's empty, and only admins can add to it.

You can populate your registry from four sources:

SourceDescription
Pre-vetted catalogBrowse and approve servers from MintMCP's curated list
Remote MCPConnect external servers running in your own infrastructure
Hosted connectorDeploy open-source or custom MCP servers in MintMCP's managed runtime
Custom serverBring your own code via the CLI and host it on MintMCP

Together these let you build a registry tailored to your organization—mixing vendor integrations, internal APIs, and open-source tools under a single governed endpoint.

See Administration for the full process of adding servers to your registry.

Custom VMCP bundles​

Rather than exposing raw connectors to users, you can bundle multiple MCPs into a single endpoint scoped to a team or use case. This is how most organizations structure their registry once they move past initial setup.

To create a bundle:

  1. Navigate to MCP store and click + Add an MCP to your registry
  2. Choose Create a role-based MCP bundle
  3. Name the bundle for its team or purpose—"Marketing Analytics", "DevOps Operations", "Sales Intelligence"
  4. Add the connectors the bundle should include
  5. Curate the tool set: enable only what the team needs, and rename or redescribe tools for clarity
  6. Set an access policy to restrict the bundle to the right group

Each bundle publishes as a single URL with centralized credentials, so users connect once instead of configuring each connector individually. Updates—adding a connector, disabling a tool, rotating credentials—propagate automatically to everyone using the bundle.

See Packaging VMCPs for teams for a full step-by-step example.

Logo customization​

Each MCP server in your registry displays a logo so users can recognize connectors at a glance in the MCP store.

Connector logos provided by Logo.dev. If a connector maps to a recognized brand—Slack, Salesforce, GitHub—the logo appears automatically without any configuration. For connectors that don't have a logo.dev match, you can upload a custom logo. This applies to:

  • Internal APIs wrapped as MCP servers
  • VMCP bundles representing a team or department
  • Open-source servers without a commercial brand

Logo guidelines:

  • Square format, since the UI displays logos in a square crop
  • SVG or PNG with a transparent background
  • Legible at small sizes (the store renders logos at roughly 32–64px)

To set or replace a logo, open the connector's configuration in the MCP store.

Custom request message​

When Allow users to request MCPs is on (the default), members browsing the MCP store see uninstalled servers with a Request button. Clicking it opens the server's detail drawer with a How to request box containing a copyable message they can send to whoever approves new servers.

Admins on an Enterprise plan can replace the default message, for example to route requests through a ticketing system instead of email or Slack:

  1. Open Enterprise settings and select the settings tab (the gear icon).
  2. Under Allow users to request MCPs, turn on Members can browse and request uninstalled servers if it isn't already.
  3. Edit the Customize request message field. It's pre-filled with the default message, and Save enables once you change it.

The message supports variables that fill in per request: {{ serverName }}, {{ organizationName }}, {{ userName }}, and {{ userEmail }}. Unknown variables are rejected at save time, so members never see a raw placeholder. Messages can be up to 2,000 characters.

Registry API​

List a user's registry catalog programmatically over the MCP registry specification's generic registry API. Each organization gets a read-only subregistry endpoint that returns the same per-user set of Virtual MCPs the MCP store shows, as standard server.json entries, so you can render the catalog inside your own portal, sync an internal directory, or drive automation against it.

Endpoints live under https://app.mintmcp.com/o/{orgRef}/registry/v0.1, where {orgRef} is your MintMCP organization ID (org_...) or your organization slug:

MethodPathReturns
GET/serversPaginated list of the user's accessible servers; supports limit (default 50, max 100), cursor, and search
GET/servers/{serverName}/versionsSingle-element version list for one server, or 404
GET/servers/{serverName}/versions/{version}One server entry; latest is supported, and every entry has exactly one version, 1.0.0

{serverName} must be URL-encoded (com.mintmcp.org-01ABC%2Fg_xyz). Each entry's remotes[0].url is the server's MCP endpoint, and MintMCP extras (the user's access level, per-connector authorization status, themed icons) live under _meta["com.mintmcp/registry"].

Requests authenticate with a delegated identity assertion: your backend signs a short-lived JWT naming the user it is acting for and presents it as the bearer token. The signing key's public half is registered against your organization by MintMCP, and per request you set iss to your registered issuer, sub to the user's email, aud to https://app.mintmcp.com/o/{orgRef}/registry, and exp at most 5 minutes out. MintMCP verifies the signature, checks the asserted user is an active member, and returns that user's catalog, so no interactive MintMCP login is needed. End-user OAuth tokens are not accepted yet.

curl -H "Authorization: Bearer $ASSERTION" \
  "https://app.mintmcp.com/o/org_01EXAMPLE/registry/v0.1/servers?limit=50"

The registry API is available on request, since key registration is provisioned per organization: contact us to enable it.