Connect AI to your own systems MCP server: that is the third decision, not the first. Start with the system people look things up in most, and give that connection read-only access. Write access comes later, one operation at a time. Build or buy is what you decide after that.
This is for an operations lead or owner who has to decide, not for someone about to write a server. There is no code here and no build cost. What MCP is sits in what is MCP; this article is about what you do with it, and in which order.
What should you connect to AI first?
The system people look things up in most, where the answer is factual. That sounds obvious and it is not, because most use-case lists start from whichever system opens up most easily.
Run these six past every system on your shortlist:
- How often does someone look something up in it? Daily, by several people, is a candidate. Monthly, by one person, is not.
- Is the answer factual or a judgement? A status, an amount, a stock level or a date is factual. “Is this client happy” is not.
- Does the data live in one place? If the same field exists in three systems with three values, the connection inherits the conflict. Fix that first.
- Who owns the system? Someone has to be allowed to decide what the assistant may see in it.
- What happens when the answer is wrong? A wrong phone number is annoying. A wrong invoice status reaches a customer.
- Can anyone on your team verify the answer? If not, a mistake only surfaces with the person who needed it.
A system that scores well on all six is rare. Ignoring two or three of them is why first connections quietly die: they work technically and nobody trusts the answer.
The uncomfortable part of this list is that the first connection is usually the least impressive one. A documentation store, a CRM field or a stock table makes a smaller demo than an assistant that creates orders, and buys considerably more trust.
Should the assistant only read, or also write?
Read first. The distinction matters more than it looks, because it decides what breaks when something breaks.
| Read only | Read and write | |
|---|---|---|
| What the assistant does | look up, summarise, compare | create, update, delete, send |
| What goes wrong | a wrong answer in a conversation | a wrong change in a system of record |
| How you recover | ask again | roll back, if that is possible |
| Who notices | the person who asked | the customer, finance, the team |
| Control that belongs with it | spot checks on answers | release per operation, plus a log |
That “per operation” is not a stylistic preference. A tool in this setup is a contract between the application and the model: the application defines which operations are available and what shape input and output take, while the model only decides when and how to call one [S-021]. You write the contract, and what is not in it cannot happen.
The connector is built for that. You can enable all tools from a server, allowlist specific tools or denylist the ones you do not want [S-065], and every tool carries an enabled field that defaults to true and can therefore be switched off explicitly [S-068]. Read-only is not a promise in that model, it is a setting: you simply never enable the write operations.
A workable sequence: read in production, run it for weeks, take spot checks. Then one write operation, the least dangerous one, with a log. Only once that is boringly reliable, the next.
When do you not need a connection at all?
More often than expected. Anthropic names the case where tool use is explicitly not needed: when the model can answer purely from its trained knowledge, such as summarising, translating or general knowledge questions [S-020]. A connection is for the opposite case, calling existing systems such as databases, internal APIs and file systems, as the bridge between a request in plain language and the system that executes it [S-019].
The connector behaves accordingly. Claude calls a connected tool when the request maps to what that tool can do according to its description, and does not call one for general knowledge questions about the connected service: asking how Notion databases work is answered directly, asking what is in your Projects database triggers the tool [S-067].
That makes a useful test before you build anything. If the question your team asks can be answered without your data, it does not belong behind a connection.
Build your own MCP server or use an existing one?
An existing one, unless there is none. When Anthropic announced the standard, pre-built servers shipped with it for Google Drive, Slack, GitHub and Postgres among others [S-001]. In Claude Code that is the daily reality too: reading design docs in Google Drive, updating tickets in Jira, pulling data from Slack or using your own tooling [S-051].
Building your own becomes interesting when your system falls outside that set: an industry-specific package, an in-house database, an internal portal. What you are really building then is the contract from the previous section, namely which operations exist, what shape they have, and what must stay out.
What that choice costs in money or hours is not in this article. There is no public source for it, and an amount without a source does not belong here. What does help the decision: the work is not in connecting, it is in deciding which operations you release. Building a custom AI tool is therefore a design question before it is an engineering question.
What do you need in place before you can connect?
Less technology than you expect, and more agreement. The documentation sets out these requirements:
- A server reachable over public HTTP. The MCP connector supports Streamable HTTP and SSE; a local STDIO server cannot be connected directly [S-066].
- A URL starting with https. That is a required field in the server definition [S-068].
- A token if the server requires authentication. The
authorization_tokenfield exists for that, and the calling side runs the OAuth flow itself and refreshes the token as needed [S-068]. - The knowledge that only tool calls work. Of the whole MCP specification, the connector currently supports tool calls only [S-066].
- An owner per server. In Claude Code a server gets a scope: this project only and private to you, or in
.mcp.jsonat the project root that you check into version control so everyone on the team gets the same tools, or available across all your own projects [S-069]. - An explicit trust decision. The documentation says to verify you trust each server before connecting it, because servers that fetch external content can expose you to prompt injection risk [S-070].
The last two are why a connection is a governance question rather than an installation. Who does that governance, and what remains after handover, is covered in who owns an automation after launch.
What this article cannot tell you
Two things, and they belong on the page. The documentation of the standard itself was not reachable while writing, so MCP is described here the way the vendor documents it. For the three decisions above that is enough. If you need the specification literally for your own implementation, go to the source of the standard rather than to this article.
The second: there are no amounts here. Not for a server, not for a build, not for a subscription. The pricing pages needed for that could not be recorded as sources, and a figure without a source is noise rather than information.
Frequently asked questions
What should we connect first? The system people query daily, where the answer is factual, and where someone can verify it. Not the system that opens up most easily. Start with read-only access and let it run for weeks before you add a single write operation.
Can the assistant change something by accident?
Not if you never enable it. Tools can be allowlisted or denylisted [S-065], and each tool has an enabled field that defaults to true and can be switched off [S-068]. What the application’s contract does not define, the model cannot call [S-021].
Does our server have to be on the internet? For the API connector, yes: the server must be publicly exposed over HTTP, and a local STDIO server cannot be connected directly [S-066]. The URL has to start with https [S-068]. Designing that without exposing your whole system is the question that shapes the build.
How do we share a connection with the team?
In Claude Code through the project scope: the configuration lives in .mcp.json at the project root, which you check into version control so everyone on the team gets the same tools [S-069]. A new connection then passes the same review as the rest of your code.
Want to know which system deserves your first connection and which rights belong with it? Book a call, or see what falls under workflow automation. What WeAdapt delivers and how your team runs it afterwards is in the FAQ. Copying data between tools by hand is usually the problem this grows out of, and that is covered in stop copying data between tools.