All insights
Every assistant needs the same five integrations. What changes for your architecture when the connector stops being bespoke.
Every assistant we have shipped in the last two years has needed the same handful of integrations: the CRM, the ticketing system, the document store, the calendar, the billing platform. Each one was written from scratch, against a slightly different tool-calling convention, and thrown away when the model provider changed.
The Model Context Protocol is the first serious attempt to make that layer boring. It is worth understanding what it changes and what it does not.
What actually standardises
MCP defines how a model-facing client discovers and invokes tools, reads resources and receives prompts from a server. The consequence is that a connector to your ticketing system is written once and works with any client that speaks the protocol, rather than once per assistant.
The connector stops being a feature of the product and becomes infrastructure, with the maintenance profile that implies.
What changes in your architecture
Three things. Authorisation moves into the server, so the question "what is this assistant allowed to touch" has one answer instead of five. Observability moves with it: every tool call crosses one boundary you can log. And the assistant itself gets thinner, which makes it easier to swap the model underneath.
The trade is that the server becomes a real service you run, version and secure. Teams that treated connectors as scripts find that the biggest adjustment.
What it does not solve
A standard invocation does not make a tool safe to call. Idempotency, rate limits, what happens on partial failure: all still yours. Nor does it decide which tools a given task should see; exposing forty tools to a model is a reliable way to get worse results than exposing four.
Use the protocol for the plumbing. Keep the judgement about scope and safety where it was: in your design.
