--- title: "Connectors Built on MCP" slug: "chapter-10-connectors-built-on-mcp" kind: "chapter" order: 11 label: "Chapter 10" chapter: 10 part: "The Data Layer" partLabel: "Part III" partNumber: 3 epigraph: "A connector is a protocol, not an integration. That difference is the whole investment thesis." summary: "The last chapter made the case for reading data in place. This one is about the mechanism: connectors built on the Model Context Protocol, what they are, why the protocol matters more than any indi…" words: 1162 topics: - "What a connector is" - "Why a protocol and not an integration" - "The catalogue a CIO should expect" - "Scoping to the person" - "Plain-English skills on top of connectors" - "What to ask a vendor about their connectors" --- The last chapter made the case for reading data in place. This one is about the mechanism: connectors built on the Model Context Protocol, what they are, why the protocol matters more than any individual connector, and what a CIO should expect a sovereign platform to ship. ## What a connector is A connector is a small service that stands between an agent and a system of record. It exposes the system as a set of tools the agent can call: look up a student by ID, list a customer's open invoices, search contracts by clause, create a ticket. Each tool has a name, a description written for a language model to read, a typed set of inputs, and a typed output. The agent sees the descriptions, decides which tool answers the question in front of it, calls it with the right inputs, and reads the result. The connector translates between the model's world and the system's. On one side it speaks the protocol; on the other it speaks whatever the system speaks: a REST API, a SQL interface, a vendor SDK, an LTI launch. It holds the knowledge of the system's data model so that the agent does not have to. In Miguel Amigot's phrase from a panel at Harvard, the connector lets an agent translate plain English into API calls against the systems where the data actually lives. That is the entire function, and it is enough. ## Why a protocol and not an integration Before the Model Context Protocol, every AI tool integrated with every system in its own way. A vendor would build "our Salesforce integration" and "our Canvas integration," and they belonged to that vendor. An institution with three AI tools had three Salesforce integrations, each maintained separately, each encoding institutional knowledge in a form that could not be shared. A protocol changes the ownership. A connector written to the protocol presents the same shape to every client. The institution writes, buys or adopts one connector per system, runs it on its own infrastructure, and any agent platform that speaks the protocol can use it. The institution's investment in understanding its own systems becomes an asset that survives any single vendor. The protocol has three other properties that matter here. It is open, with a published specification and reference implementations in several languages, so an institution's own engineers can write a connector for a system nobody else has. It is widely adopted: by 2025 the major model developers supported it, which is why a connector written for one platform works with another. And it is simple enough that a connector for a well-documented system is a few hundred lines of code, not a project. ## The catalogue a CIO should expect A sovereign platform should arrive with connectors for the systems its market actually runs, and a way to add the rest. For higher education: the student information system (Banner, PeopleSoft, Jenzabar, Colleague), the learning management system (Canvas, Blackboard, D2L, Moodle), the CRM for recruitment and advancement (Slate, Salesforce), the identity directory, the ticketing tool, the document stores. For enterprises: the CRM, the ERP, the HR system, the support desk, the project tools, the collaboration suites, the data warehouse. For healthcare: the electronic health record through its sanctioned interfaces, scheduling, the clinical document store, with the data classification rules from Chapter 6 applied at the broker. For legal and financial services: matter and case management, document management, the billing system, the research databases, market and reference data. Across all of them: the generic connectors for file systems, databases, web pages, calendars and email that most real tasks touch somewhere. The number matters less than the pattern. A platform that ships a few dozen connectors and a clear way to write the next one, with the connectors running inside the institution's perimeter, is in a different category from one that ships a hundred integrations running in its own cloud. ## Scoping to the person The property that turns a connector from a convenience into a governance tool is how it authenticates to the source system. The wrong way, and the common way, is a single service account with broad read access. The agent can then see everything the service account can see, and the only thing standing between a curious user and another person's record is the model's judgement about what to retrieve. That is not a control. The right way is to call the source system as the person asking, or with a scope derived from their role. A student asking an advising agent about their own transcript triggers a call to the student information system under that student's identity, and the system returns that student's transcript and nothing else. An advisor asking about their caseload gets their caseload. The source system's own permission model does the work it already does for the system's native interface. This requires that the identity flowing from the client, through the agent, to the connector is the real user's identity, which Part IV covers, and that something between the agent and the connector enforces it, which is the broker in the next chapter. A connector catalogue without those two pieces is a liability with good documentation. ## Plain-English skills on top of connectors Connectors give an agent the ability to reach a system. They do not tell it when, in what order, or what to do with the result. That knowledge lives in skills: instructions, written in plain language, that describe how to accomplish a task using the tools available. A skill for "prepare a student's registration hold summary" might say: look up the student, list their holds, for each hold find the office responsible, draft a summary in this format, flag anything older than thirty days. It names the connectors' tools and the steps. It is written by someone who knows the process, not by an engineer, and it can be read and corrected by anyone. The sovereign platform I work on ships over a hundred and sixty such skills, each a readable file, covering platform operations as well as institutional tasks, and institutions add their own. The practical effect is that the people who understand the work can shape what the agents do without a development cycle, and the connectors underneath stay generic and reusable. ## What to ask a vendor about their connectors Five questions sort the market quickly. Do the connectors speak the Model Context Protocol, so they work with other platforms, or are they proprietary to yours? Where do they run: inside my perimeter, or in your cloud? Do they call my systems as the asking user, or as a service account? Can my engineers write one for a system you have never seen, with your documentation and no professional services engagement? And when a connector calls a system, where is the credential, and who can see the log? The last question is the one that leads to the broker, and the next chapter answers it.