AI can't do much without context. It's almost literally like putting a capable assistant in a dark room and asking them to help. Give them a light — your data, your systems, your actual business goals — and they can move toward it. So how do you get the light to an AI agent working on behalf of your campus?
That's what the Model Context Protocol, or MCP, is for.
Standing up a first MCP server takes about twenty minutes. Pick an SDK, define a tool, point it at something, watch an agent call it. It works. The room gets a little excited. Somebody starts talking about a chatbot that can actually answer real questions.
And then somebody asks how long it would take to do that against the systems the institution actually runs on, and the temperature in the room changes.
That's the question worth being ready for, because the honest answer depends almost entirely on things nobody wants to bring up during a demo. Where does the system live. Who is the agent acting as. What happens when it writes something. In a lot of the campus environments we work in, the answers are “a server down the hall,” “nobody has decided,” and “please do not.”
So here's the architecture conversation the way we'd actually run it, plus a note at the end about why this work is worth taking seriously now.
Hybrid is the normal case
A lot of the AI hype cycle assumes every institution has already moved its on-prem systems into a cloud tenant with modern identity sitting neatly in front of it. This is hilariously incorrect for higher ed. What actually exists is some systems in a data center, some in the cloud, an identity provider bridging both, and a set of integrations somebody built under deadline pressure years ago and has been afraid to touch since.
Sometimes that's a failure to modernize. More often it's just what a long migration looks like from the inside, whether the holdup is resistance or budget, and the result is the same either way: a mess. Half your data has a modern API in front of it, and half of it lives behind an export that runs at 2am. Identity works differently depending on which system you're standing in front of. Nobody has a complete picture of what talks to what, and the person who built the last piece of it left the institution two reorgs ago.
Dropping an AI agent into that without a plan is an expensive way to learn a lesson. You'll get a demo, then a pilot, then a quiet meeting about why the numbers never moved. Automation reads what you actually have, not what you meant, and a hybrid environment gives it a lot of material to work with.
The good news is that MCP genuinely doesn't care where an API runs. It cares about three things: whether the agent can reach it, whether it can prove who it's acting for, and whether it gets back something predictable. Every hard decision downstream is a version of one of those three, and most institutions cannot confidently answer any of them today.
Where does this thing actually live
First real architectural decision, and it's a meaningful one.
The agent usually runs somewhere the institution doesn't control. The SIS, CRM, or ERP runs somewhere it very much does. Something has to bridge that gap, and the wrong answer is opening an inbound path to a core system because a pilot needed it before the end of the semester. That's how you end up explaining a firewall rule to an auditor two years later.
The shape we'd propose: treat the MCP server as the only thing reachable from outside, sitting in front of APIs that stay unreachable. It lives at the edge, in a DMZ or behind a gateway the institution already runs, and it holds no student data of its own. Internal systems keep exactly the exposure they have today, which is to say none. This framing also makes a pilot dramatically easier to get approved, because if it gets cancelled, you tear down one component instead of unwinding network changes nobody remembers making.
For genuinely locked-down environments — and higher ed is usually one of them, alongside healthcare — an outbound-initiated tunnel is worth putting on the table. A connection your network opens is a much easier approval than a port somebody else opens into it. Either way, the principle holds: the agent talks to the MCP server, the MCP server talks to your APIs, and those are two separate trust decisions that deserve to be made separately by people who are actually reviewing them.
This is the same reasoning behind splitting internal and vendor-facing APIs onto separate surfaces. An agent surface is a third boundary with its own threat model, and it earns its own front door for exactly the same reason the other two did.
Identity is the whole game
The tempting shortcut is a service account with broad rights and a static key sitting in a config file. It works immediately. It demos beautifully. It also quietly converts every access decision the institution has ever made into a single credential that can do anything on behalf of anyone — which is the sort of thing that comes up in a security review roughly nine seconds after you present it.
The better path: the MCP server acts as a resource server, not an authorization server. It validates short-lived, scoped tokens issued by the identity provider the institution already runs, rather than minting its own. In a hybrid environment, that's the correct answer anyway, because agent access ends up governed by the same directory and the same groups that govern everything else. You're not standing up a parallel permission system that will drift from the real one inside of a year and quietly become the thing nobody wants to own.
A few details worth getting right: bind tokens to a specific resource, so a token minted for one MCP server can't be replayed against another. Don't pass tokens through to upstream APIs — exchange them for one scoped to that downstream service, so a compromise at one hop doesn't turn into access to everything behind it.
Take this seriously, because the broader ecosystem currently isn't. Independent research on live, publicly reachable MCP servers has repeatedly found a large share exposing tools with no authentication mechanism at all, and another sizable share leaning on static tokens or API keys anyone could copy. Whatever you build is probably not going to be the weakest thing out there. That's a very low bar, and a genuinely terrible thing to aim at.
An MCP server is not your API with a hat on
The most common design mistake is mirroring a REST surface one to one. Forty endpoints become forty tools, the agent gets a catalog it can't reason about, and every call asks a model to assemble something a human developer would have needed documentation to piece together.
A tool is a task, not a route. “Look up a student's current enrollment status” is a tool. Six chained lookups and a join across three systems is not a tool — it's homework. If completing a common request takes an agent four calls in a specific order, that sequence should have been one tool with a name that says what it does.
You're designing an interface for a reader that can't walk over and ask a coworker what a field means, which makes the tool description and the response shape the interface, not documentation about the interface. Keep the catalog small and curated. Fewer, well-named tools with clear descriptions beat exhaustive coverage every time, and the fastest way to make an agent unreliable is to hand it thirty plausible options for the same job.
Be extremely deliberate about which tools write. Read access is recoverable. Write access is a decision about what an agent is allowed to do to a student's record on a Tuesday afternoon, and it deserves its own line in the scope document rather than arriving as a side effect of exposing a resource because it was convenient.
Keep the human where the judgment is
Good agent design lets a tool pause mid-call to ask for a confirmation or a missing parameter rather than guessing or barreling ahead. The agent assembles everything, stages the work, and stops at the exact point where a person needs to approve the thing that has consequences. Automate the retrieval and the formatting. Ask before the write that somebody is going to have to answer for later.
It's also, practically speaking, a much easier design to walk a nervous provost or registrar through than a diagram of everything the model has promised not to do.
Where the work is
Here's the part we find genuinely interesting, and the reason this is worth more than a pilot.
Every institution we've worked with has a list of deferred integration work: clean up the API surface, consolidate identity, retire the export that gets emailed every Friday to a distribution list with four names that no longer work there, document the endpoints. That work has always been correct and almost never funded, because the business case was “things will be tidier,” and tidier doesn't win a budget meeting against an enrollment or retention initiative.
AI agents changed the shape of that argument entirely. The exact same cleanup now has a visible payoff attached to it, and leadership is asking for the payoff directly. That doesn't make the work any easier. It makes it fundable, which was the actual blocker for the last decade.
The second thing that makes this attractive is that it doesn't require replacing anything. An MCP server is an adapter, and an adapter in front of a system nobody wants to touch is a far smaller ask than a migration. You're not proposing to rip out the SIS the institution runs on. You're proposing a curated surface in front of it, and the legacy system underneath gets to go on being a legacy system in peace. That phases beautifully: one read-only tool, then a second, then the write path once trust exists, with every phase producing something usable instead of a milestone on a slide.
Which means the real deliverable is rarely the MCP server itself. It's the reachable API. The scoped credential. The identity model that finally got sorted out. The documentation that finally got written because something other than a human had to read it. The protocol work is the small part. The modernization it justifies is the engagement — and it's the kind of work that leaves an institution better off even in the scenario where the whole AI strategy looks different in three years.
Where to start
Pick one read-only tool against a system people already ask questions about. Put it behind the institution's real identity provider on day one, because retrofitting auth after a successful pilot is a conversation nobody has ever won. Log every call with who requested it and what came back, since the first question after any incident is what the agent actually did, and “we're not totally sure” is a rough thing to say out loud to a provost.
Then leave it alone for a few weeks and watch what people try to do with it. The second tool is dramatically easier to design once you have evidence instead of a roadmap.
None of this is really about agents. Reachable APIs, centralized identity, scoped credentials, tools named after tasks, audit logs that answer questions. It's the same list it's always been, the one everyone nodded along to and then deprioritized. The agents just make it painfully obvious which parts got skipped.