MCP Data Flow Architecture
How AI agents connect to institutional systems through Model Context Protocol
MCP-Compatible Clients
Any MCP-compatible AI agent or application connects to the broker through a single interface
MCP Broker
Central orchestration layer — routes requests, enforces policy, caches responses, provides observability
Query Routing
Maps tool calls to the correct MCP server based on intent and payload
RBAC Enforcement
Checks requester role against tool policy before forwarding — deny-by-default
Response Caching
Configurable TTL per tool — cached data inherits the same access controls
Observability
Logs every request and response — metrics for latency, error rates, query patterns
MCP Servers
Each server is a thin wrapper around one system's API — exposes capabilities as tools with defined inputs, outputs, and permissions
LMS MCP Server
Canvas, Blackboard, Moodle, Open edX, Brightspace
SIS MCP Server
Banner, Colleague, PeopleSoft, Workday Student, Jenzabar
Advising MCP Server
EAB Navigate, Starfish, SSC Campus
Degree Audit MCP Server
DegreeWorks, Stellic, uAchieve
CRM MCP Server
Slate, Salesforce, Ellucian CRM
Financial Aid MCP Server
Banner FA, PowerFAIDS, Workday FA
Identity / SSO MCP Server
Shibboleth, CAS, SAML, Azure AD
Source Systems
Data is queried in place — MCP does not replicate or move data between systems
LMS
Canvas / Blackboard / Moodle
SIS
Banner / PeopleSoft / Workday
Advising
EAB Navigate / Starfish
Degree Audit
DegreeWorks / Stellic
CRM
Slate / Salesforce
Financial Aid
Banner FA / PowerFAIDS
Identity / SSO
Shibboleth / Azure AD
MCP Security Model
Defense-in-depth — security enforced at every layer of the MCP data flow
RBAC at the Broker
Every request is checked against the requester's role before forwarding. Deny-by-default — tools must be explicitly enabled per role.
PII Minimization
Input validation before calling upstream APIs. Output filtering to strip data the requester does not need.
Scoped Service Accounts
Each MCP server authenticates with its own credentials, scoped to only the operations it needs.
Audit Logging
Every tool call is logged: requester identity, tool name, parameters, timestamp, outcome. Immutable logs routed to your SIEM.
Transport Security
mTLS between broker and servers. TLS for all external API calls. No plaintext transport anywhere in the chain.
Data Residency
MCP servers run inside your data center or cloud tenancy. Data is queried in place, not copied to external systems.
Complete MCP Data Flow Sequence
- 1AI agent or MCP-compatible client initiates a tool call (e.g., a cross-system query)
- 2Request arrives at the ibl.ai Switchboard MCP Broker via the MCP protocol
- 3Broker authenticates the requester via SSO and resolves their roles and permissions
- 4Broker checks RBAC policy — does this role have permission to call this tool? Deny-by-default (FERPA enforced)
- 5Broker routes the request to the appropriate MCP server based on the tool name and routing rules
- 6MCP server authenticates with its scoped service account to the backend system
- 7Backend system returns raw data — MCP server filters the response for PII minimization based on requester role
- 8MCP server writes an immutable audit log entry (requester, tool, parameters, timestamp, outcome)
- 9Filtered, structured result returns through the broker to the requesting agent
- 10Agent combines results from multiple MCP servers into a single, coherent answer for the user
Role-Based Data Access
The broker enforces what each higher education role can see — FERPA compliance is operationalized here
| Campus Role | LMS | SIS | Advising | Degree Audit | CRM | Financial Aid |
|---|---|---|---|---|---|---|
| Academic Advisors | Caseload grades | Enrollment, GPA | Full (own caseload) | Progress, what-if | — | — |
| Registrar Staff | — | Full (all students) | — | Full access | — | — |
| Faculty | Own sections only | Own students only | — | — | — | — |
| Financial Aid Staff | — | SAP data | — | — | — | Full access |
| Enrollment Mgmt | — | — | — | — | Prospects + admitted | Package status |