The install is free, the week after is not
Somebody on your team found an MCP server on GitHub, pointed Claude at it, and had a working tool call in ten minutes. MCP is the open protocol AI clients use to call tools in other software. The install cost was zero. Then the second person asked for it, then the finance team asked who could see what, and then somebody left. That is where open source MCP servers vs paid stops being a license question.
That gap is the whole argument. Nobody disputes that open source MCP servers are free to install. The question is what you sign up to operate once more than one person depends on them. Then you decide whether that work is worth paying somebody else to do.
Open source MCP servers vs paid: what you are actually buying
The choice in open source MCP servers vs paid is not a license fee against a subscription. It is who does the operating work: sign-in, credential storage, per-person access, the audit trail and offboarding. A free server hands all five to you, per server.
| Operating item | Local open source server | Self-hosted remote server | App vendor's own server | Elaichi Gold |
|---|---|---|---|---|
| Sign-in | You implement it, per server | You implement it once | The vendor's, per app | One OAuth server behind one endpoint |
| Credential storage | A config file on each laptop | Yours to encrypt and rotate | The vendor's | Separate credential service, AES-256-GCM |
| Token refresh | Yours | Yours | The vendor's | Credential service; a failed refresh marks the connection |
| Per-person access | Everyone or nobody | Yours to build | The app's own permission model | Role plus restrictions |
| Audit trail | Yours to build | Yours to build | Per app, in that app | One log per organization, 90 days |
| Offboarding | Re-read each device | Yours to build | Per app | One preview, then one removal |
| Who runs it | You | You | The vendor | Elaichi |
That is not a criticism of the projects. A self-installed server is built for one developer on one machine, and it does that job well. The cost arrives when the thing becomes company infrastructure and nobody budgeted for it as infrastructure.
Two shapes of free server exist, and they fail differently. A local server runs on each person's laptop and is configured in a file there. Cursor reads MCP servers from .cursor/mcp.json in a project and ~/.cursor/mcp.json in the home directory (Cursor docs, checked October 2026). Claude Code keeps local-scope and user-scope servers in ~/.claude.json (Claude Code docs, checked October 2026). A self-hosted remote server runs on infrastructure you own and reaches everyone at once. The first multiplies by headcount. The second concentrates into one thing you now have to run.
What does operating a self-run MCP server actually involve?
Six items, and each one is work somebody does repeatedly rather than once.
Sign-in. Every client has to authenticate. Cursor supports OAuth for MCP servers that require it. It uses fixed redirect URLs, https://www.cursor.com/agents/mcp/oauth/callback for web and http://localhost:8787/callback for the desktop app (Cursor docs, checked October 2026). VS Code needs the authorization server to allow http://127.0.0.1:33418 and https://vscode.dev/redirect. It tries Dynamic Client Registration first and falls back to client credentials (VS Code docs, checked October 2026). Claude uses a Client ID Metadata Document only when the server advertises both client_id_metadata_document_supported: true and none in its token endpoint auth methods (Anthropic docs, checked October 2026). Otherwise it registers dynamically. You are implementing an authorization server that satisfies several clients' assumptions at once.
Credential storage. Each connected account's secret has to live somewhere encrypted, be fetched for the call that needs it, and be rotatable. Rotation is the part that gets skipped and then matters.
Token refresh. A connected account's OAuth token expires. Something has to notice and refresh it. When the refresh fails, it has to mark the connection as needing a person's attention rather than failing a tool call silently.
Per-person access. Who may reach which tool. On a self-run server this is usually either everyone or nobody, because writing a per-person authorization layer is a project rather than a config file.
The audit trail. Which person called which tool, against which account, from which client, and whether it worked. Retention, search and export are all separate problems after you have the records. What an AI audit log has to capture lists the fields that turn out to matter.
Offboarding. When somebody leaves, every server they configured on their laptop keeps whatever credentials they put in it. Every shared server keeps the account they connected. None of the client admin pages read in October 2026 documents an admin inventory of the MCP servers in members' local config files (Claude Code managed MCP docs, checked October 2026). You cannot offboard what you cannot list.
Where the cost scales, and where it does not
The operating work does not scale with usage. It scales with two other numbers: how many servers you run, and how many people touch them.
One server, one developer, local config: the work is roughly nothing. One server, forty people: sign-in, credential storage and the audit trail each become real, but you build them once. Six servers, forty people: you build them six times. Or you build a gateway in front of them, which is the same decision with extra steps.
The second multiplier is the one that catches teams out. Each client's distribution story is different, and adding an approved server to an allowlist is not the same as putting it on people's machines. Adding a server to Cursor's MCP allowlist approves a configuration but does not push it to users' machines (Cursor docs, checked October 2026). Team members still configure it in their own settings. Claude Code's allowedMcpServers and deniedMcpServers are filters, not a registry (Claude Code docs, checked October 2026). A server still has to be added by a user, a plugin or the organization before either list applies. So even with a tidy policy, the per-person configuration work remains.
When the free path genuinely wins
Three cases, and they are not edge cases.
One person, one server, one laptop. A developer running a local server against their own account is not infrastructure. There is nobody to govern, no credential to share, and no offboarding beyond wiping the laptop. Paying for governance here buys nothing. When you don't need an MCP gateway yet walks through the test.
A vendor runs the server and you only need one app. Most of the apps a team playbook covers now ship an MCP server of their own. Each one runs under that app's own permission model (Notion MCP overview, checked October 2026). It reads and writes only what the authorizing user can already access there. If your whole need is Notion, connect Notion's server and stop. No second vendor, no gateway, no subscription. The case for putting it behind something else is one address and one set of rules across several apps. Vendor MCP servers through Elaichi sets that out.
You have a platform team and a reason to self-host. If data cannot leave your network, or you already run gateways and have the rota to cover them, self-hosting is a defensible answer. Running your own MCP servers: the real cost is the longer version of that arithmetic.
What a paid control plane does instead
Elaichi serves MCP at one endpoint, https://api.elaichi.ai/mcp, the same address for every organization. Which organization, person and tools a client reaches comes from the OAuth grant behind its token, not from the URL. That removes the per-server sign-in work, because there is one authorization server rather than one per server.
The operating items are answered where they sit. Connector credentials are not kept in Elaichi's main data. A separate credential service holds each connected account's secrets in encrypted form. Elaichi fetches them into memory only for the call that needs them. Secrets are encrypted at rest with AES-256-GCM, and the key can be rotated without re-encrypting old rows. Token refresh belongs to that credential service. When a refresh fails during a tool call, the connection is marked as needing re-authentication rather than failing quietly.
Access is a role plus restrictions. A restriction rule targets a role or one member, names whole connectors or single tools, and is checked before the call leaves Elaichi. Every call that reaches execution is written to the audit log with the person, the connector, the connection and the MCP client. Elaichi keeps 90 days of audit history; for longer, forwarding to your own log service comes with the Black plan, which is launching soon.
Offboarding is one action with a preview. GET /member/:userId/offboarding returns the departing member's whole estate before anything changes. That is the connections they own, their toolboxes, templates and custom connectors, and the toolbox entries anywhere in the organization that rely on them. Removing them revokes their MCP client grants and API tokens and removes their membership. It does not remove or deactivate their accounts in the connected apps. Those stay in place until they are deprovisioned in each app or through the identity provider.
The catalog matters to this comparison too, because it changes how many servers you run. Elaichi authors and runs most connectors in its catalog. It governs vendors' own MCP servers for the rest, and lets a team bring its own remote MCP server under the same rules. Adding your own remote MCP server needs the connector:create permission, which among system roles only Org Owner and Org Admin hold. It also needs the custom connectors feature, which Gold includes.
What it costs, and the trade-offs
Gold lists at $15 per user per month in USD, or $10 per user per month billed annually. Every new organization starts on a 14-day Gold trial that needs no payment details. Elaichi has two plans, Gold and Black. An organization without an active one of them is locked until somebody subscribes. Check the pricing page for the price in your own country.
Three honest trade-offs. First, Elaichi is hosted, not self-hosted, so if your requirement is that nothing leaves your infrastructure, this is the wrong shape. Second, per-seat pricing means a large team paying for governance it may only need for a few people; MCP gateway pricing: per seat vs per call compares the models. Third, prompt injection is the client's problem, not the endpoint's. A tool call carries a tool name and arguments, so Elaichi never receives the person's prompt and has nothing to judge a call against. Nothing on that path scans tool results for injection.
The arithmetic is plainer than it looks. If you run one server for one person, keep it. If you are about to implement sign-in, credential storage, access and audit for the third time, price the engineering weeks against the subscription. Decide on that, not on the license.
