Connect your tools to an assistant you can still leave

The pitch usually arrives as a plugin. Your CRM, your accounting tool or your project tracker announces that it now works inside a chat assistant, and the demo is genuinely good. You ask a question in the chat window, you get an answer off live data, and you stop opening four tabs to assemble it yourself. So you connect it, then you connect two more, and within a month the assistant is the first thing you open and the last thing you close.

The bill for that arrives later, and it is not a subscription. It arrives the day the assistant you standardised on changes a default, raises a price, or falls behind a rival, and you discover that the whole shape of your working day is now built inside a window you would rather leave. This guide is about connecting tools in a way that keeps that door open. It is not for a company with a procurement function and a security review, which has different questions and more people to answer them, and it is not for developers shipping a connector as a product, who should be reading the specification instead. It is for a one- to ten-person operation with three or four business tools and one assistant subscription.

The connector is a standard, not a favour from your vendor

What sits under almost every one of these integrations is the Model Context Protocol. It is an open protocol that uses JSON-RPC 2.0 messages between three roles: hosts, which are the applications that start a connection, clients, which are the connectors inside the host, and servers, which are the services offering data and capabilities [1]. Servers can expose resources, prompts and tools; the current revision of the specification is 2026-07-28 [1].

The part that matters commercially is who owns it. MCP has been established as Model Context Protocol a Series of LF Projects, LLC, with code and specification contributions made under the Apache License 2.0 [2]. Its governance document is explicit that membership in the technical governance process is for individuals rather than companies, with no seats reserved for specific firms [2]. That is not a guarantee of neutrality forever, but it is a materially different arrangement from a plugin format owned by whoever is currently winning.

All three of the assistants a small team is likely to be choosing between document support for it. Claude takes remote connectors over Streamable HTTP, with Dynamic Client Registration, token refresh and a documented OAuth callback [4]. OpenAI documents remote MCP servers for apps in ChatGPT and through the Responses API [5], and describes apps in ChatGPT as built with MCP so the assistant can call approved tools [6]. Google documents remote MCP servers in the Gemini API’s Interactions API, where you supply a server name and URL, optional auth headers, and an allowed_tools array restricting what the model can reach [7].

So the wire is portable. If your accounting tool exposes an MCP server, the same server is reachable from more than one assistant, and switching does not require your vendor to build anything new. That is the good news, and it is worth knowing before you accept anyone’s argument that you have to stay.

What locks you in sits above the connector, not inside it

The connection moves. The work you build on top of it does not.

Everything an assistant adds around a connector is proprietary: the saved prompts, the project or workspace that holds your context, the memory, the packaged skills a vendor ships for that specific assistant, the directory listing, the admin configuration. Claudeforce is the clearest example of the pattern. In August 2026 Salesforce and Anthropic announced Salesforce in Claude, a plugin with 37 prebuilt sales skills covering work like meeting prep, deal health review and pipeline review, available to select pilot customers immediately, with an open beta expected in September 2026 and further prebuilt skills in late 2026 [8]. The skills are the product. The connection is the commodity underneath them.

Read that as the durable lesson rather than the news. Large vendors will meet you inside whichever window you already work in, because that is cheaper than persuading you to come back to theirs. What they build there is shaped for that window, and it does not travel. If your team’s actual operating procedure lives inside 37 skills that exist in one assistant, you have not avoided lock-in by choosing an open protocol. You have moved it up a layer, where it is harder to see.

The defence is dull and it works. Keep the instructions that encode how your business does things in files you own, in your own document store, and paste or attach them. Treat a vendor’s packaged skills as convenience, not as the definition of the process. When you write down a workflow, write it so a competent stranger could follow it, because the next assistant is that stranger.

Read-only until it has earned more

The first connection should not be able to change anything.

OpenAI’s own compatibility guidance points the same way. For ChatGPT deep research and company knowledge, a server should implement two read-only tools, search and fetch, and the documented example skips approval for exactly those two because they are read-only; the instruction alongside it is to keep approval enabled for tools that can modify data or take other consequential actions [5]. That is the whole policy in one sentence, and it applies just as well to a two-person business as to an enterprise.

The specification’s security guidance goes further on permissions. It names scope minimisation as its own problem: broad tokens granted up front expand the blast radius of any leak, make revocation disruptive because pulling one token breaks every workflow, and turn your audit trail into noise [3]. It lists using wildcard or omnibus scopes such as all or full-access among the common mistakes, and recommends starting with a minimal set and elevating when a privileged operation is first attempted [3]. The consumer version of that advice is simple. Connect with the narrowest account you can, live with the read-only version for a couple of weeks, and add write access to one tool at a time, when a specific job has failed for want of it.

A tool description is a claim, not evidence

The specification is blunt about what a connected tool is. Tools represent arbitrary code execution and must be treated with appropriate caution, and descriptions of tool behaviour such as annotations should be considered untrusted unless they come from a trusted server [1]. Hosts must obtain explicit user consent before invoking any tool, and users should understand what each tool does before authorising it [1].

OpenAI states the risk in operator terms: an attacker may use a prompt injection attack to leak sensitive information through a write action to a custom MCP server, and its recommendation is not to connect to one unless you know and trust the underlying application [5]. The shape of the attack is worth holding in your head. It needs a connector that can write or send, some content the assistant reads that you did not write, and enough permission for the instruction hidden in that content to do damage. A support inbox connector plus a web page the assistant summarises is the whole recipe.

Local servers are a separate category of risk. Running one on your own machine means running a binary with the same privileges as your client, and the guidance requires a client offering one-click local setup to show the exact command without truncation before executing it [3]. Read that dialog. On the server side, the rule that stops a compromised connector becoming a skeleton key is that servers must not accept tokens that were not explicitly issued for them [3], which is the kind of thing you can ask a vendor about in one line of email and learn a lot from the answer.

Connectors are a window, not a pipe

People design workflows that a connector cannot carry, then blame the model.

The published limits are specific. On Claude’s hosted surfaces a tool result is capped at roughly 150,000 characters, with a 300 second timeout, while Claude Code allows 25,000 tokens by default and is configurable [4]. The transport is Streamable HTTP, and the legacy HTTP and server-sent events transport is being deprecated [4]. Gemini’s remote MCP support works only with Streamable HTTP servers, and server-sent events servers are not supported [7]. Claude’s documentation also lists resource subscriptions and sampling as not yet supported [4], which is a reminder that a host implements the parts of a specification it has got to, not all of it.

Two practical consequences. First, a connector is for asking a question against live data, not for hauling a quarter of records into a chat window; if the job is bulk, export the file and attach it. Second, portability is real but approximate. Claude documents support for the 2025-03-26, 2025-06-18 and 2025-11-25 authorization specifications [4] while the current protocol revision is 2026-07-28 [1], so hosts trail the standard by design. Expect a switch to need re-authorising, not rebuilding.

Run the switch as a drill, not as a plan

The only way to know your exit is cheap is to walk it once.

Pick a day, open the assistant you do not use, connect the same two or three servers, and run three jobs you actually did last week. Time it. Write down what broke, which instructions you had to retype, and which of them you could not find because they lived in a saved prompt rather than a document. That list is your real lock-in, and it is usually two hours of work that you can fix this quarter and not one you will discover in an emergency.

While you are there, check the defaults on the plan you are paying for, because they differ. Apps in ChatGPT are enabled by default on Business plans and disabled by default on Enterprise and Edu plans, with admin controls for role-based access, which actions apps may perform, and which account domains can connect, and all app calls logged in OpenAI’s compliance logs [6]. Claude connectors are added from Customize then Connectors on its hosted surfaces [4]. Neither of those is a permanent fact. Both are worth re-reading each time you add a team member.

What still goes wrong

Trust is still your job. The protocol standardises how a server talks to an assistant. It says nothing about whether the people running that server are competent, or solvent next year. OpenAI reduces its own guidance on custom servers to a judgement you have to make yourself, which is not to connect unless you know and trust the underlying application [5]. The specification’s security document reads as a catalogue of live attacks, from confused deputy attacks in OAuth proxies to state handles treated as authentication [3]. That is what a maturing standard looks like rather than a reason to panic, and it is a reason to treat a connector as a supplier decision, judged on the evidence you would demand from any other supplier.

Portability stops at the protocol. Nothing in MCP moves your conversation history, your memory, your projects, or the packaged skills a vendor built for one assistant, and nothing obliges a host to implement every part of the standard [4]. Reasonable people over-read the word open here. It means you will not need a new integration built for you. It does not mean a switch is free.

And the deepest lock-in has no technical fix. Once a team has spent six months learning where things are in one window, moving costs attention at the exact moment you are usually moving because something has gone wrong. The drill above is the only real answer, and most people will not run it. If you do nothing else from this guide, get your operating instructions out of a vendor’s prompt library and into a file with your name on it.