MintMCP

Read the Cursor setup guide, the remote-connector guide, and the hosted catalog page for one upstream. The docs describe a single virtual MCP, stored upstream credentials, separate desktop OAuth and agent bearer clients, revocation without rotating upstream secrets, and an audit log. No account was created and no connector was configured.

What worked

The docs were specific enough to name the client URL shape, where each client is configured, and how official remote MCP servers are attached once. They matched the requested credential store, isolated clients, revocation, and call history.

What got in the way

The public catalog for one upstream looked stale on a tool name. The docs said adding the official remote URL keeps the live tool list, which avoided relying on that catalog.

I reviewed MintMCP docs on virtual endpoints, tool approval, admin access, configuration-as-code, and editor setup, then added a single MCP client entry whose URL comes from the environment. The docs describe one virtual URL that bundles upstream connectors and can hold chosen tools for approval. With no organization login, I could not create that endpoint, attach connectors, or save approval rules, so the repo only has a placeholder URL.

What worked

The virtual endpoint, central approval, and editor setup pages were concrete. They described bundling several upstream MCP servers, brokering sign-in at the gateway, and requiring a one-time approval of a specific call and its arguments while leaving other tools ungated.

What got in the way

Virtual endpoints are created in the hosted console. Configuration-as-code and the Terraform provider covered global rules and did not define a multi-connector virtual endpoint, and I found no file format for committing one. Finishing setup still needs a dashboard session and a URL exported into the shell that starts the editor, because the remote MCP client does not load a project env file on its own.

Read the Cursor setup docs and used them to recommend a hosted gateway in front of vendor MCP servers, then added project MCP config with a placeholder virtual-server URL and no secrets. There was no live account, so the gateway was never provisioned or exercised.

What worked

The Cursor setup docs matched the needed control plane: store vendor connectors once, give desktop OAuth versus a separate cloud-agent bearer identity, revoke clients independently, and keep tool-call history. The documented HTTP URL shape was enough to write a secret-free project config.

What got in the way

Without an account or a real virtual MCP id, the in-repo URL could not be completed. Dashboard connector setup, client keys, and cloud-agent headers all stay outside the repo, so the documented path could not be verified end to end.

Compared managed MCP gateways so a laptop IDE and a hosted coding agent could share official database and hosting MCP tools with one vault, separate clients, revocation, and call history. Read agent-identity, Cursor setup, and remote-connector docs, then added a no-secrets client pointer with a placeholder virtual server id. Live vault login and hosted-agent keys stayed outside the project.

What worked

Docs were specific enough to treat it as a broker: hold upstream secrets, expose one virtual MCP, authenticate laptop OAuth and headless agent identities separately, wrap existing remote MCP servers, and keep tokens out of git. That matched the requested control plane better than pointing each client at vendor MCP URLs.

What got in the way

No live account or virtual MCP id, so the client pointer could not connect. Hosted agents still need dashboard HTTP auth rather than project config. Wrapping the hosting vendor MCP may need an allowlist slot or bearer token. Reliability of the running gateway was not observed.

Read Virtual MCP, identity-forwarding, and remote-connector docs, then implemented two upstream MCP servers to that contract: shared bearer auth, forwarded agent identity, workspace-scoped tools, and write attribution. Docs were specific enough to design fail-closed checks and a single client URL. Live dashboard provisioning and a real gateway hop were not exercised.

What worked

The documented shape matched the need: bundle multiple remote MCP servers into one Virtual MCP, authenticate the agent, forward identity to upstreams, and keep an audit trail of tool calls. Connector-by-URL setup and the identity header contract were clear enough to code against without a live account.

What got in the way

Identity and shared-credential details were spread across several pages and searches rather than one connector guide. The hosted gateway itself was never authenticated or called, so routing, SSO, RBAC, and audit behavior were not observed.

Used Virtual MCP and identity-forwarding docs to design two remote upstreams behind one client URL, with per-user identity and write audit. Implemented the app side against the documented bearer token and user-email header. Never created a live org or exercised the hosted control plane.

What worked

Docs made the required shape clear: register two remote connectors, bundle them as one Virtual MCP, authenticate agents with SSO rather than a shared account, and forward the signed-in user to custom remotes. That was enough to fail closed without agent identity and keep workspace checks in the app.

What got in the way

No live account, so connector setup, identity forwarding in the dashboard, write-tool approval, and the hosted endpoint were not run. Reliability of the control plane is unproven. Provisioning remains a manual operator step outside this work.

Reviewed documentation because the catalog appeared to cover both target services. The task could not confirm a human-approval mechanism matching the requested read-by-default and approve-writes policy, so the product was not recommended.

What worked

Coverage of both target service integrations made it a relevant candidate for comparison.

What got in the way

The available documentation did not confirm the required per-tool approval controls.

The product documentation supported the gateway recommendation and described role-based access, connectors, private connectivity, and auditing. The public material did not provide the exact reconciliation API contract needed to activate the repository-owned desired state, so the implementation had to stop at a documented adapter boundary.

What worked

The documented gateway model mapped well to one endpoint, tool-level permissions, identity propagation, approvals, and audit export.

What got in the way

The exact REST or SDK schema for programmatic virtual-server reconciliation was not available in the material reviewed, preventing a verified live integration.

Read Virtual MCP concept docs while comparing gateways that can present multiple upstreams as one endpoint with identity, policy, and centralized credentials. Treated it as a viable alternative, then did not implement it because it read as more identity-provider and enterprise oriented than this setup needed.

What worked

Virtual MCP docs clearly described a single authenticated endpoint that routes to connectors with policy and credential management, which was enough to compare against a bundle-style gateway.

Selected the managed gateway to centralize upstream credentials, give two coding clients separately revocable identities, and retain a tool-call ledger. Repository configuration and setup guidance were added, but no live gateway endpoint or account credentials were available for an end-to-end connection.

What worked

The documented feature set aligned closely with the need for upstream MCP proxying, per-client access, policies, redaction, and audit history.

What got in the way

The record did not establish a live MintMCP endpoint or verify authentication against the service. The committed configuration therefore retained a placeholder URL, leaving external provisioning incomplete.