MCP without JSON config files: one URL, OAuth

Why do teams end up editing JSON on every laptop?

Because the first MCP server somebody runs is almost always local, and local servers live in files. A Node or Python process sits on their machine. A block in a config file names the command and its arguments. An API key lives in an environment variable or, more often, pasted straight into the file. It works on that laptop. Then the next person copies it from Slack. Elaichi replaces that file with one address every client signs into, where each person approves their own grant.

That is where MCP without JSON config files becomes worth the effort. The config file is not only a setup chore. It is a place where a credential lives in plain text, on a machine your admin console does not inventory. The format drifts the moment one person changes a flag. As of October 2026, none of the client admin pages for Claude Code, Claude Desktop, Cursor, VS Code, Devin or Codex document an inventory of what MCP servers are configured in members' local config files (Claude Code managed MCP, checked October 2026). The only way to find out what is configured is to ask people, one at a time.

The alternative is a remote MCP server. One HTTPS address, added in each client's own settings, with sign-in handled by OAuth instead of a pasted key. MCP (Model Context Protocol) is the open standard that defines how an AI client discovers and calls tools exposed by a server. The distinction that matters here is transport, not protocol. Both local and remote MCP servers speak the same MCP messages. A remote server is reachable over HTTPS by any client, with no process running on the user's machine.

What does MCP without JSON config files actually look like?

It looks like one URL and one browser sign-in per person, per client. Elaichi serves MCP at a single endpoint, https://api.elaichi.ai/mcp, and that is the same string for every organization. There is no per-user, per-team or per-toolbox address to generate. The address carries no token: the access token travels only in the Authorization header. The endpoint speaks MCP over the Streamable HTTP transport, as JSON-RPC 2.0 messages.

Which organization and which person a client reaches comes from the OAuth grant behind its token, not from the URL. A grant is the standing permission one person approved for one named client, in one organization. Two people can paste the same address and reach different tools, because each approved their own.

The client registers itself through OAuth dynamic client registration (RFC 7591). Registration is open and needs no Elaichi-issued credential ahead of time. There is no client ID, secret or header for a person to look up. They add the URL, and the browser opens Elaichi's consent screen. They pick their organization and approve what the client asked for, and the client stores the tokens itself.

Elaichi's shape is one static endpoint, OAuth dynamic client registration, and a per-person grant behind the token. What sits behind that grant is where vendors differ. How tools are surfaced, how access is scoped, how credentials are stored, and what the audit trail captures. Those differences are the part worth evaluating vendor by vendor.

What does each client's own settings screen offer?

Most clients now have a place to add a remote server without touching a file. The paths differ, so here is what each vendor documents. These are vendor-controlled UIs and will change. Treat the specifics below as current to the checked date, not permanent.

Claude. On Team and Enterprise plans, an Owner or Primary Owner adds a custom connector from Organization settings > Connectors. They click Add, hover over Custom and choose Web. Members then find it under Customize > Connectors and click Connect to authenticate (Anthropic support, checked October 2026). On Pro and Max, the user opens Customize > Connectors, clicks + Add and chooses Add custom connector. Claude reaches the server from Anthropic's cloud, not from the user's device, so the server has to be reachable over the public internet (same page, checked October 2026).

ChatGPT. Admins and owners create a custom MCP app from Workspace settings, then Apps, then Create. They give the server's endpoint and metadata, pick an authentication mechanism, click Scan Tools, complete the authorization prompt if the server uses OAuth, and then click Create (OpenAI help, checked October 2026). Publishing is a separate step, from Workspace settings, then Apps, then Drafts, then Publish.

Cursor. Cursor supports OAuth for MCP servers that require it, and Team admins can distribute shared MCP servers from Dashboard > Plugins & MCPs (Cursor docs, checked October 2026). On a live check of Cursor 3.24 on 2026-10-16, a server added with only a url was listed as "Needs authentication" with an Authenticate button. Selecting it opened Elaichi's sign-in and consent screen, which named Cursor as the requesting app. After Allow access, Cursor listed Elaichi as connected with its tools enabled. This is a single run on a single build. It is not a guarantee of behavior on other Cursor versions.

Microsoft Copilot. It reaches Elaichi through a Copilot Studio agent that adds Elaichi's MCP endpoint as a tool, with OAuth set to Dynamic discovery. Elaichi's product team confirmed on 2026-10-21 that sign-in and connected tools work in this configuration. That is a first-party report, not an independently reproduced test. Microsoft Copilot is not a verified client in Elaichi's console, so its entry shows the name the client registered for itself rather than a vetted display name.

What can an admin push centrally, and what can they not?

Admins can approve, distribute and block a server. They cannot skip the per-person sign-in. Admin distribution is per client, and the vendors mean different things by it.

On Claude Team and Enterprise, an Owner adds the custom connector once for the organization. Each member then authenticates individually, and enabling a connector gives nobody access by itself (Anthropic support, checked October 2026).

In Cursor, selecting Add to Team Marketplace under Team MCP Servers makes a standalone Team MCP server available in the Agent Window, IDE and CLI. Teammates install and configure it from Customize. Linking it to a marketplace does not install or enable it for everyone (Cursor docs, checked October 2026). Cursor's Enterprise-only MCP Allowlist sits under MCP Configuration in the team dashboard. It approves a configuration but does not push the server to users' machines (Cursor enterprise docs, checked October 2026).

In VS Code, per-server ChatAllowedMcpServers and ChatDeniedMcpServers policies exist from version 1.130. A deny entry takes precedence over an allow entry (VS Code docs, checked October 2026).

A per-tool control in a client cannot do per-app work here. Per-tool client permissions see Elaichi's connected tools as a few tool names, execute_tool, read_tool and run_code, so they cannot tell one connected app from another. Gating execute_tool alone leaves read_tool and run_code. Per-app and per-tool control is set in Elaichi, as restrictions.

That limitation on sign-in is structural, not a product gap. It is what makes the audit trail name a person rather than a shared account. Any vendor's remote-MCP implementation that lets an admin bypass it is trading traceability for convenience.

How should you evaluate any config-file-free MCP setup?

Start from the three ways per-laptop config files fail, and ask how a given setup addresses each. Independent of which vendor's gateway you use, those failures compound:

1. Credential exposure. The config file holds whatever the person pasted into it. Typically that is a personal API token carrying that person's full account privileges, created once and rarely rotated. There is no scoping between what the AI can do and what the human who pasted the key can do.
2. State drift. Each machine's config file is independently edited. There is no canonical version, so six machines end up in six different states with no reconciliation step. Concretely: Claude Code keeps local-scope and user-scope servers in ~/.claude.json, and project scope in .mcp.json at the project root. Codex uses ~/.codex/config.toml. Devin's Cascade uses ~/.config/devin/mcp_config.json on macOS and Linux (Claude Code MCP, Codex, Devin, all checked October 2026). Three clients, three file formats, three locations, none of which a central admin console reads.
3. Revocation lag. With a pasted key, removing someone's access means finding every file that holds a copy of that key, across however many laptops it reached. There is no single point where revocation is guaranteed to take effect.

Any remote-MCP-with-OAuth approach is a bet that moving the credential off the laptop and behind a per-person grant fixes these three failure modes. Whether it actually does depends on vendor-specific implementation details. What follows is specific to Elaichi and should be read as such.

How does Elaichi address the three failure modes?

It moves the credential into a separate service, resolves identity from the grant rather than the machine, and re-reads that grant on every call. The following describes Elaichi's own architecture, as documented by Elaichi. It is not independently audited. Read it as a vendor's account of its own system rather than a verified third-party fact.

Credential exposure. Elaichi states that it does not store a connector credential in readable form anywhere in its stack. According to Elaichi's architecture documentation, a separate credential service holds each connected account's secrets encrypted at rest, with AES-256-GCM. It fetches them into memory only for the duration of the call that needs them. The AI client itself never sees the app's API key. It holds only an Elaichi-issued OAuth token.

Drift. Every client points at the same URL, and the server resolves identity and scope from the OAuth grant. So there is one source of truth for what this person is allowed to reach, independent of which machine or client they are using.

Revocation. With a pasted key, revocation requires finding every copy. With a grant, a person disconnects an app under Settings, then Connected apps, or an admin removes them from the organization. Elaichi states that every MCP request re-reads the grant, so revocation takes effect on the next call rather than on a delayed sync cycle. Grants are listed and disconnected individually. Each grant in Connected apps is labeled with the browser and operating system that approved it. The audit entry written at consent records the client, the scopes and the toolbox reach.

What does the central endpoint give you that a file cannot?

It puts the controls on the server rather than on the laptop. Once every client points at one address, four things follow.

Tools are found rather than listed. Elaichi does not return every connected tool in a single tools/list response, however few tools exist. Instead, the model finds a connected tool with search_tools and runs it with read_tool (a read) or execute_tool (anything), or with run_code under Code Mode. Each search result says which of the two to use. The model searches for the capability it needs by description, then invokes it by exact name. This matters mechanically. MCP clients typically load the full tool list into the system prompt on every turn. An organization with 40 connected tools across a dozen apps would otherwise burn context-window budget on every single message, used or not. Search-based discovery keeps that cost flat regardless of catalog size. Other MCP gateways have made this design choice differently. Check how any gateway you evaluate handles tool-list size before you connect more than a handful of apps.

execute_tool is only a naming indirection. It unwraps to the tool name and arguments it was given, then goes through the same gates as a direct call by that name. read_tool unwraps the same way and meets the same gates, then refuses anything that is not a connected read.

Access is checked per call, for the caller. A restriction targets a role or one named member, as in this walkthrough of blocking one Stripe tool for the Member role. Elaichi has no organization-wide or team-wide restriction target. The clamp runs on every path a call can take: tools/call, execute_tool, read_tool, run_code and the toolbox and synthetic-tool operations. A tool a restriction withholds is omitted from what the server advertises to that caller. A direct call to it is refused with a message indicating an admin can lift it through an access request. A role or restriction change reaches every surface in about two minutes. Revoking a share, disconnecting an account, or removing a member takes effect on the caller's next call, not on a scheduled sync.

Arguments can be locked. A frozen parameter on a toolbox entry fixes an argument value for calls routed through that entry, and the caller cannot override it. The model can see that a value is frozen, and often what it is, but cannot change it. This only holds for calls through that specific entry. The underlying connection stays unshared, and anyone with direct access to that connection has the same tool without the lock. A frozen parameter is a constraint on one path to a tool, not a server-wide policy.

Every call that reaches execution writes an audit entry: the person, the connector, the connection, the tool, the surface and the MCP client that sent it. Elaichi retains 90 days of audit history by default. For longer retention, Elaichi's Black plan supports forwarding to an external log service via a logging destination.

What do you give up by centralizing on one remote endpoint?

Four things, and they apply to this pattern generally, not just to Elaichi:

• Single point of failure. If the gateway has an outage, every client that depends on it loses tool access at once. Per-laptop local servers fail independently and rarely all at once.
• Vendor lock-in on the grant layer. Every person's OAuth grant, every restriction and every frozen parameter lives in the gateway vendor's system. Switching gateway providers means re-doing the per-person consent flow for the whole organization, not just updating a config file.
• Rate limits move from per-key to per-organization. A personal API key pasted into a local config file has its own rate budget from the underlying app. Routed through a shared gateway, multiple people's usage can compete against a single upstream credential or quota, depending on how the connector is configured.
• You are trusting the gateway's claims about credential handling. The encryption and isolation claims above are not independently audited in this post. If credential handling is a compliance requirement, ask any MCP gateway vendor for a SOC 2 report, pen-test summary or security whitepaper rather than taking a blog post's word for it. Elaichi's own certifications are published in its Trust Center.

None of this argues against the remote shape over per-laptop files. The three failure modes above are worse on a laptop. It argues for treating which gateway as a real decision with real tradeoffs, not a solved problem once you have picked remote over local.

When is a config file still needed?

In two cases, and neither is an argument against the remote shape.

Local stdio servers. A server that runs a process on the machine, reads a local database or talks to something on localhost is configured in a file by definition. A remote endpoint cannot replace that. A remote MCP connector added to Elaichi must be reachable over public HTTPS: no localhost, no IP literals, no internal hostnames.

Clients whose remote entry is itself a file. Cursor reads MCP servers from .cursor/mcp.json in a project and ~/.cursor/mcp.json in the home directory, and a remote server entry is defined with a url field (Cursor docs, checked October 2026). On the same 2026-10-16 live check, "New MCP Server" opened the user-level file in an editor. This is still a materially different shape from a local stdio config. The file holds one line with a URL and no credential, and sign-in happens in the browser via OAuth. If that file leaks, it leaks a public address with no embedded secret, a meaningfully smaller blast radius than a leaked API key.

If the only MCP use case is one internal tool on one engineer's laptop, keep the local server and skip all of this. A single person prototyping does not need OAuth registration, consent screens and an audit log. The remote shape earns its cost when more than one person needs the same app, and somebody has to be able to answer who reached what, and when.

The order to do it in

1. Connect the apps in Elaichi first. Each person signs in to the app with their own account where per-person permissions matter. Start with adding a first connection.
2. Write the restrictions you want before anyone connects a client. A role or restriction change reaches every surface in about two minutes.
3. Give people the one URL, https://api.elaichi.ai/mcp. In the web app, Connect your AI client shows it with a copy button.
4. Have each person add it in their client and approve their own grant, picking their organization and the scopes they need.
5. Check the audit log. Every call that reaches execution is written with the person, the connector, the connection and the MCP client.

If a client refuses to connect, the OAuth error guide walks through the usual causes. If it connects but shows no tools, start here instead. For the broader case against per-laptop setup, see replacing personal MCP servers. For client-by-client walkthroughs, the setup posts cover Claude, ChatGPT and Cursor. The connector catalog lists what each app exposes, across 650+ connectors.