MCP & Connecting Tools

To see why open protocols matter, look at what happens without them. Suppose a studio wants its agents to reach several things - the project files, the BIM model, the client database, a pricing service, a rendering tool. In a bespoke world, every agent needs a custom connector built to each tool, in that tool's particular way. Three agents and five tools is fifteen bespoke connections to build, test and maintain; add a tool and you rewire every agent; change a tool's interface and every connector to it breaks. This is the N-times-M problem: the wiring grows with the number of agents multiplied by the number of tools, and it is exactly the kind of brittle, duplicated plumbing that makes integrations expensive and fragile. It is also why, for years, connecting AI to real systems was a specialist job done one painful integration at a time.

An open protocol collapses that tangle. Instead of every agent knowing every tool's private language, everyone agrees on one standard: a tool exposes what it offers - its data and its available actions - once, in the protocol's format, and any agent that speaks the protocol can use it without a bespoke connector. Now adding a tool means writing one standard connector that every compliant agent can immediately use; adding an agent means it can reach every compliant tool already connected. The wiring stops multiplying. This is the same move that made the web work - agree on shared protocols (HTTP, HTML) and any browser can talk to any server - applied to the connection between agents and the tools, files and data they act on.

The payoff is not just less plumbing; it is reuse and ecosystem. When connection is standardised, connectors become shareable building blocks: someone writes a good connector to a common tool once, and everyone whose agents speak the protocol can use it. A studio building on a standard is not trapped rebuilding basic integrations; it inherits a growing library of them and spends its effort on what is specific to its own work. That is the quiet, structural reason protocols matter - they turn integration from a repeated bespoke cost into a shared, compounding asset - and it is why the agentic ecosystem has moved decisively toward standard connective layers rather than one-off wiring.

The Model Context Protocol is, as of 2026, the leading open standard for this connective layer, and it is worth understanding as an idea even if you never implement one. In plain terms, MCP defines a common way for an AI agent to connect to a server that exposes some resource - your files, a database, a design tool, a live data source - and to discover what that server offers and use it, all through one standard rather than a bespoke integration. The agent is the client; the thing being connected sits behind a server that speaks the protocol; and the protocol is the agreed language between them.

Three elements make the idea concrete. First, a protocol server declares what it offers: this is the data you can read, these are the actions you can take, described in a standard way the agent can discover - so an agent can ask a compliant tool 'what can you do?' and get a structured answer, rather than needing that knowledge hand-coded in advance. Second, the agent can then use those declared capabilities - read the resource, call an action - through the same standard channel, whatever the underlying tool. Third, and crucial, the server is where access is defined and bounded: what the agent is allowed to see and do lives at the server, so connecting an agent does not mean handing it the keys to everything - it means giving it exactly the access the server exposes, under whatever permissions and gates that server enforces. The permission boundary sits at the connection point by design.

The honest framing, in keeping with this whole course, is that MCP is the prominent example as of 2026 of an idea that will outlast any particular standard: a shared, open protocol for connecting agents to the tools, files and data they need. The specific name may change; the direction - away from bespoke, per-tool wiring and toward standard, discoverable, permissioned connection - is durable. For a designer, the value of understanding it is not to build a server but to recognise, when choosing agents and tools, whether they speak a common standard - because that choice largely determines whether your agents will interconnect cleanly with your studio's systems or trap you in one-off integrations and a single vendor's walled garden.

Interoperability - the ability of different tools and agents to work together through shared standards - sounds abstract until you translate it into the realities of running a design practice, where it decides several things that matter a great deal. The first is avoiding lock-in. A studio whose agents connect to its tools through an open standard can change one piece - swap a model, adopt a better agent, replace a tool - without ripping out and rebuilding all its integrations, because everything speaks the common language. A studio wired through one vendor's proprietary connectors is captive: its automation only works while it stays on that vendor's terms, pricing and roadmap. In a field moving as fast as this one, the freedom to change your mind cheaply is worth a lot, and open standards are how you keep it.

The second is connecting the tools you actually use. Design practice runs on specialist software - BIM, CAD, rendering, analysis, project management - and the value of agents in that practice depends on their reaching those tools, not just generic apps. As specialist tools expose themselves through standard protocols, agents can reach the real substance of design work rather than only its email-and-spreadsheet edges. A studio choosing tools and agents that speak a common standard is investing in a future where its agents can work with its actual design systems; one choosing closed tools is betting its automation stays shallow. The third is compounding capability: standard connection means each new connector the ecosystem produces is one your agents can use, so your capability grows with the field rather than only with your own build effort.

But interoperability also concentrates a responsibility, and this is the part a professional must hold. A standard, easy connection is still a connection to your real files, data and tools - and the easier it becomes to plug an agent into everything, the more deliberate you must be about what you plug it into and what you let it do. Interoperability lowers the technical barrier; it does not lower the confidentiality, security or professional stakes. Connecting an agent to your client database through a slick standard protocol is exactly as serious a data decision as it would be through a bespoke one - arguably more so, because it is easier and therefore easier to do carelessly. The studio benefit of interoperability is real and worth pursuing; it comes with the duty to govern connection as deliberately as the standard makes it easy.

The convenience of standard, discoverable connection makes it more important, not less, to treat every connection as a permission and trust decision. The through-line holds all the way down to the plumbing: giving an agent access to a tool is giving it the ability to read your data and act on your systems, and that must be scoped, bounded and gated on purpose - the ease of the protocol is not permission to skip the judgement.

Start with least privilege at the connection. A good protocol server lets you expose exactly what an agent needs and no more - read-only where reading is enough, a limited slice of data rather than the whole store, a defined set of actions rather than everything the tool can do. Configure connections that way by default: the narrowest access that lets the agent do its job, so a mistake or a compromise does the least harm. Next, keep the human gate on consequential actions. Standard connection makes it trivial for an agent to not just read but write, send, change and delete through a tool, so anything that carries consequence - modifying a live model, issuing a document, altering client records, spending money - stays behind a human approval step, exactly as in the earlier lessons. Easy connection raises the stakes of a runaway agent precisely because it can now reach so much; the gate is what keeps that power safe.

Then there is trust in what you connect to. An open ecosystem of shareable connectors is a genuine benefit, but a connector is a piece of software that sits between your agent and your data, so a connector from an unknown source is a security question - what does it really do, where does your data flow, can it be trusted with the access it asks for. Prefer connectors and servers you or a trusted party control or that come from reputable sources, and apply the same data-and-confidentiality discipline as everywhere in this module (Module 8.3): know where your data goes before you connect. Finally, verification does not change: an agent reaching more tools through a clean protocol is still an agent that can be confidently wrong, and you remain the author and the architect of record for whatever it does with that reach. Interoperability is a powerful good - it makes agents genuinely useful in real practice - but it is a capability to govern, not a reason to relax. Connect widely where it earns its keep, scope every connection tightly, gate the consequential actions, trust your connectors deliberately, and verify what matters.