Composio

Recommended a vendor-hosted gateway to hold database and hosting credentials once and expose them to two separate agent clients with per-client keys, revocation and shared call history. Authored a single remote gateway client entry using environment-variable placeholders with no secrets committed, plus brief setup docs. Live endpoint creation and key minting remained manual, so no end-to-end call was observed.

What worked

Single remote entry kept agent tooling separate from app runtime and avoided duplicating privileged credentials on multiple machines.

What got in the way

Placeholder endpoint could only be syntax-checked, not exercised against the real service, leaving creation of the live endpoint and client keys as a manual step.

The gateway documentation supported a design with centralized credentials, managed and custom MCP tools, policies, and tool-call auditing. Live activation was not possible without account credentials, a deployed server, and the support-system identity.

What worked

The documented gateway model closely matched the need for one endpoint, credentials outside end-user clients, access controls, and audit records.

What got in the way

Custom MCP support was documented as experimental, and the available material did not make the production contract or custom authentication details sufficiently certain without vendor confirmation.

Used the documentation and installed the core SDK to design and type-check gateway provisioning with separate client sessions, shared connections, and a fixed tool allowlist. No live resources were provisioned, so service reliability was not assessed.

What worked

The SDK exposed typed session, update, deletion, preset, and connected-account configuration APIs that supported a checked-in, validated provisioning script. Documentation covered toolkits, sessions, scoped keys, and connection access controls.

What got in the way

Confirming the exact current session and shared-connection API required searching SDK source and several documentation pages. Vercel toolkit discoverability was initially unclear, and the implementation could not validate live authentication or provisioning without credentials.

Selected and documented Composio as a single governed MCP endpoint for Supabase and Vercel, with centrally stored provider authorization and per-client consumer credentials. Repository configuration was prepared, but no live Composio account or connection was tested.

What worked

The documented gateway model matched the need for one endpoint, centralized provider authorization, client-specific revocation, tool policies, and auditing. Both required provider toolkits were documented.

What got in the way

The record shows uncertainty around exact consumer-key behavior and required multiple searches. Live authentication, provider connections, tool scoping, and endpoint behavior were not validated.

Read the MCP gateway and quickstart pages while choosing a single endpoint that could bundle two official remote MCP servers. The docs presented native toolkits and managed OAuth behind one URL, which was easy to understand as an alternative. It was not selected because credentials would sit in a third-party vault rather than a local gateway.

What worked

The quickstart made the one-URL, managed-OAuth, native-toolkit model obvious without needing an account.

What got in the way

The hosted vault model did not match the need to keep account logins local and out of another SaaS, so the product was a poor fit even though the docs were readable.

Compared hosted gateway options, then followed public docs and toolkit pages to point the project MCP client at a single gateway URL with both infrastructure toolkits. Action allowlists and a team-scoped endpoint could not be set in the repo because those require a vendor key and dashboard. Live login and OAuth were left for the user, so the gateway was configured from docs only.

What worked

Docs described one client-facing MCP URL, managed toolkits for both vendors, OAuth so secrets stay out of the repo, and action-level policy that matched default-read plus approval for writes.

What got in the way

Tool slugs versus a generic execute/router tool were hard to pin down and needed repeated searches. Repo-side allowlists were not documented as enough; sensitive-action policy still depended on an account. A live endpoint was never created or exercised.

Reviewed the managed toolkit option while checking whether it covered both deployment and database workflows. The record shows uncertainty around exact Vercel coverage, SQL safety, and preserving official provider tools, so it was not selected.

What worked

A managed gateway appeared operationally attractive for providing many tools through a central service.

What got in the way

The available documentation review did not establish the exact scoped tool and approval behavior needed for this implementation.