Claude connects to business systems through MCP servers that each vendor publishes. What you can actually do once connected is decided by that vendor's list of permitted actions, not by Claude, which is why one connection feels transformative and the next feels like a toy.
Most disappointment with these connections traces back to that single sentence.
The three kinds of connection
Hosted by the vendor. The software company runs an MCP server and you authorise it. This is the common case now and the easiest: closer to connecting an app than to installing one.
Run by you. You run a server that exposes something of your own, usually an internal database or a system nobody has covered yet. This is a development project, not a setting.
Through a gateway. A middle layer connects to many systems and presents them as one. Convenient, and worth checking carefully, because the permissions now belong to the gateway rather than to you.
What decides whether it is useful
Not the assistant. The action list.
| If the vendor publishes | You get |
|---|---|
| Read actions only | Answers about data you already have |
| Reads plus narrow writes | Answers, plus the small updates that follow |
| Reads plus full writes | The work itself, with you approving it |
| No list you can see | A sales claim you cannot evaluate |
The last row is more common than it should be. "We support MCP" is now a feature bullet, and it survives scrutiny only until you ask which actions it publishes. Ask. The answer is a list, it is short, and it tells you in thirty seconds whether a connection is worth setting up.
What it is genuinely good at
Three jobs, in order of how much time they save.
Questions nobody wrote a report for. Which clients have not moved since the last review. Which deals went quiet after the proposal. Reports answer the questions somebody anticipated. This answers the one you have now.
Drafting from a current record. A client update, a quarterly summary, a follow-up that refers to what actually happened. The value here is not the writing, it is that the writing starts from the real record instead of from memory.
The small update after the question. You ask what is behind, you decide what to do, and the action gets created without you opening another tab. This only works where the vendor publishes writes, which is why that question matters.
What it is not good at
Anything that has to happen on a schedule with nobody present. An MCP connection does nothing until it is asked. Payroll on the 15th, a nightly sync, an invoice run: those are integrations, and they should stay integrations.
It is also poor at anything requiring the assistant to hold a long chain of state across systems. It works one question at a time, and that is a feature rather than a limitation, but it means "run our month end" is not the job.
The permission question, briefly
A connection acts as you. That is the right model, and it has a consequence people miss: if you have broad access, so does the assistant you connected.
Before connecting anything to real business data, check three things. Whether actions are logged and attributable. Whether access can be withdrawn in one place rather than per person. And whether the server acts as the connecting user rather than as an administrator.
Where Empiraa sits
Empiraa GPS shipped its MCP in version 1.22, so a compatible AI assistant can work with the plan, the owners and the progress, within your permissions and nothing beyond them. It is included on every Professional Services tier. Signal's own MCP is in build and has not shipped at the time of writing, which is exactly the kind of thing this post argues you should make vendors say out loud.
Related reading: what an MCP server is, and what it is not, and what an AI assistant can see in your strategy.
See also can ChatGPT change my plan, which is the write question asked a different way.
