Publish, connect, discover, choose, act. The step worth understanding is the fourth, because that is where the assistant decides for itself rather than following a route somebody mapped in advance.
Everything else is ordinary software plumbing.
The five steps
1. The system publishes. A vendor runs an MCP server in front of their product and writes down what it will allow: list open deals, read this quarter's progress, create an action. Each entry has a name, a plain description and the information it needs.
2. You connect. You authorise the assistant to use that server. The connection carries your permissions, so it can reach what you can reach and nothing more.
3. The assistant discovers. When you ask a question, the assistant reads the published list. It does this at the time of asking rather than from something memorised, which is why a vendor adding an action makes it available without anyone updating a configuration.
4. The assistant chooses. It matches your question to an action. "Which clients have not moved since the last review" becomes a decision to call the action that lists clients and progress. Nobody wrote a rule for that question. This is the step that is new.
5. The system acts. The server runs the action with your permissions and returns the result, which the assistant turns back into an answer.
Then it stops. The connection goes dormant until the next question.
Why step four is the whole point
Before this, connecting software to software meant deciding in advance what would be asked. You chose the question, a developer wrote the path to the answer, and the result was a report or a sync. Anything nobody anticipated required another build.
Step four removes the anticipation. The assistant works out which action fits a question that did not exist when the server was written. That is the difference between a report and an answer, and it is the reason this pattern is worth the attention it is getting.
It is also why the results vary so much between vendors. The assistant can only choose from what was published, so a short list of read-only actions produces a narrow assistant no matter how good the model is.
What the published list looks like in practice
| The question you ask | The action it picks | What comes back |
|---|---|---|
| What is behind this quarter | List objectives with progress | The ones off pace |
| Why did that client go quiet | Read activity for a client | Last contact and what it was |
| Add a follow up for Priya | Create an action, if writes exist | Confirmation, or nothing |
That third row is where most connections stop. If the vendor publishes reads only, the assistant can tell you what to do and cannot do it, which is still useful and is not what most people picture when they hear the word agent.
Two things that trip people up
It is not running in the background. No schedule, no watching, no overnight job. If you need something to happen whether or not a person is present, that is an integration.
It is not a data transfer. The assistant asks specific questions and gets specific answers, the way a person gets a screen. Nothing is copied anywhere and nothing is held.
What to check before connecting
Whether actions are logged and attributable. Whether access can be withdrawn in one place. Whether the server acts as the connecting person rather than as an administrator. And the list itself, which takes a minute to read and tells you more than any amount of vendor copy.
Where Empiraa sits
Empiraa GPS shipped its MCP in version 1.22. A compatible assistant sees the plan, the owners and the progress you can see, within your permissions, and is included on every Professional Services tier. Signal's MCP is in build and has not shipped at the time of writing.
Related reading: what an MCP server is, and what it is not, and MCP vs API.
What an MCP actually is answers the same question for someone deciding whether to switch it on.
