MCP Architecture Guide: From Data Sources to Cross-System AI Agents

Most organizations have the data they need spread across five to fifteen systems. The LMS knows about course engagement. The SIS knows about enrollment and standing. The CRM knows about prospects and outreach. HR systems know about employees, benefits, and org structure.

The problem is that each system has its own API, its own auth model, its own schema, and its own rate limits. Every time you build something that needs data from more than one system — a dashboard, a workflow, an AI agent — you re-solve the integration problem from scratch.

Model Context Protocol (MCP) is an open standard that fixes this. You build one thin wrapper per system (an "MCP server"), add a broker that routes and governs requests, and then any application or agent can ask cross-system questions through a single, stable interface.

This guide walks through the process step by step.

1. Inventory Your Data Sources

Before writing any code, you need a clear picture of what systems you have, what data each one holds, and what APIs are available. For each system, document:

• System name and vendor — e.g., Canvas (Instructure), Banner (Ellucian), Workday
• What data it holds — courses and grades, enrollment and standing, employee records, etc.
• API availability — REST, GraphQL, SOAP, flat-file exports. Note which operations are read-only vs. read-write.
• Authentication model — OAuth 2.0, API keys, SAML, service accounts. Note any token refresh requirements.
• Rate limits and quotas — Requests per minute, daily call caps, pagination behavior.
• Data sensitivity — PII, FERPA-protected records, PHI, financial data. This determines access controls.

The goal is not to wrap every system on day one. Pick the two or three sources that matter most for your first use case and start there. You can add more MCP servers later without changing any existing applications.

2. Build MCP Servers for Each Source

An MCP server is a thin wrapper around one system's API. It exposes that system's capabilities as "tools" — structured operations with defined inputs, outputs, permissions, and audit behavior.

One server per system

Keep each MCP server focused on a single source system. An LMS MCP server wraps LMS API calls. An SIS MCP server wraps SIS API calls. This means when the LMS vendor ships a breaking API change, you update one server and nothing else breaks.

Define tool schemas

Each tool has a name, a description (so agents know when to use it), input parameters, and output shape. The tool name becomes the stable contract that applications depend on.

mcp_server.add_tool(
    name="get_student_course_status",
    description="Return current grade and missing-work
                status for a student in a course",
    parameters=["course_id", "student_id"],
    policy={
        "rbac": ["advising.read", "instructor.read"],
        "pii_minimization": True,
        "audit": True
    }
)

Notice the policy block: this tool requires either the advising.read or instructor.read role. PII minimization strips unnecessary personal data from the response. Every call is audited.

Security defaults

Every MCP server should ship with these defaults:

• System-scoped service accounts — each server authenticates with its own credentials, scoped to only the operations it needs.
• Deny-by-default tool exposure — tools must be explicitly enabled. No open-ended API passthrough.
• Input validation + output filtering — validate parameters before calling the upstream API. Filter PII from responses.
• Request signing / mTLS — mutual TLS between the broker and servers so both sides verify identity.
• Complete audit logs — requester identity, tool name, parameters, timestamp, outcome.

3. Add an MCP Broker

With individual MCP servers in place, the broker is the layer that ties them together. Applications and agents talk to the broker; the broker routes requests to the right MCP server, enforces policy, caches responses, and provides observability.

What the broker does

• Routes queries — the agent asks "get this student's grades" and the broker knows to call the LMS MCP server.
• Applies policy — checks that the requester has the right role before forwarding the call. Enforces data minimization rules.
• Caches responses — avoids hammering upstream APIs with repeated identical queries. Configurable TTL per tool.
• Observability hooks — logs every request and response. Feeds metrics to your monitoring stack (Prometheus, Datadog, CloudWatch).
• Rate limiting — protects source systems from overload. Configurable per server, per tool, per requester.

Broker vs. direct connection

You can connect agents directly to individual MCP servers for simple setups. But for any deployment with more than two or three servers, a broker gives you centralized policy enforcement, cross-cutting observability, and a single point to manage credentials and routing. It is the difference between connecting wires individually and using a switchboard.

4. Connect Agents and Ask Questions

Once the broker is running, any MCP-compatible agent can connect to it. The agent sees a list of available tools (from all connected MCP servers) and can call whichever tools it needs to answer a question.

This is where the architecture pays off. When an advisor asks "How is this student doing?" the agent can:

1. Call get_student_course_status on the LMS MCP server to pull current grades and missing work.
2. Call get_enrollment_standing on the SIS MCP server to check enrollment status and credit count.
3. Call get_degree_progress on the Degree Audit MCP server to check requirements remaining.
4. Combine the results into a single, coherent answer.

The agent does not need to know how Canvas's REST API works, what Banner's endpoint structure looks like, or how to authenticate to either system. It calls stable tool names, and the MCP servers handle the rest.

The same pattern works with any MCP-compatible client: agents on ibl.ai's Agentic OS, Claude Desktop, custom applications, dashboards, or automated workflows.

5. Reference Architecture

The full architecture has three layers: applications and agents at the top, the MCP broker in the middle, and individual MCP servers at the bottom — each wrapping one source system.

┌─────────────────────────────────────────────────────┐
│  APPLICATION / AGENT LAYER                          │
│  (AI agents, advising copilots, dashboards,         │
│   early-alert workflows, chat interfaces)           │
└──────────────────────┬──────────────────────────────┘
                       │
                       ▼
┌─────────────────────────────────────────────────────┐
│  MCP BROKER                                         │
│  Routes queries · Applies policy · Caches           │
│  Rate limits · Observability hooks                  │
└───────┬──────────────┬──────────────┬───────────────┘
        │              │              │
        ▼              ▼              ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ LMS MCP      │ │ SIS MCP      │ │ Advising MCP │
│ Server       │ │ Server       │ │ Server       │
│ (API wrapper)│ │ (API wrapper)│ │ (API wrapper)│
└──────┬───────┘ └──────┬───────┘ └──────┬───────┘
       │                │                │
       ▼                ▼                ▼
   LMS APIs         SIS APIs      Advising APIs

Adding a new system means adding a new MCP server and registering it with the broker. Existing applications and agents do not change — they just gain access to new tools.

6. Example: University — "How is this student doing?"

An academic advisor opens the advising copilot and types: "How is Jordan Martinez doing this semester?"

What happens behind the scenes

1. The agent recognizes this is an academic standing question and calls three tools through the broker:
   • get_student_course_status (LMS) — returns current grades, missing assignments, last activity date per course.
   • get_enrollment_standing (SIS) — returns enrollment status, cumulative GPA, credit hours completed.
   • get_degree_progress (Degree Audit) — returns requirements completed vs. remaining, estimated graduation term.
2. The broker checks that the advisor has the advising.read role, logs the request, and forwards each call to the appropriate MCP server.
3. Each MCP server calls its upstream API, filters the response for PII minimization, and returns structured data.
4. The agent combines the three responses into a single answer:

The advisor got a cross-system answer in seconds. No one had to build a custom dashboard or write a report. The same query can be triggered automatically as an early-alert workflow: if missing assignments exceed a threshold, generate the summary and route it to the advisor's queue with a full audit trail.

Other university queries this enables

• "What courses does this student need to graduate?" — Degree Audit MCP server + SIS MCP server.
• "Which students in this section haven't submitted anything in two weeks?" — LMS MCP server, filtered and grouped.
• "Send a check-in message to students who dropped below a 2.0 this term." — SIS MCP server (identify students) + communications tool (send message). Logged and auditable.

7. Example: Enterprise — "How is this employee's onboarding going?"

An HR business partner opens the internal assistant and asks: "How is Priya Sharma's onboarding going?"

What happens behind the scenes

1. The agent calls three tools through the broker:
   • get_employee_onboarding_status (HRIS) — returns start date, department, manager, onboarding checklist progress.
   • get_training_completions (LMS) — returns required training modules, completion status, overdue items.
   • get_open_tickets (Ticketing) — returns IT provisioning requests, equipment orders, access requests still pending.
2. The broker verifies the HR partner has hr.read access and logs the query.
3. The agent combines the results:

The HR partner sees the full picture without logging into three different systems. The overdue training and pending GitHub access are immediately actionable. The same query can run automatically on day 7, 14, and 21 of every new hire's onboarding, with summaries routed to the manager and HR partner.

Other enterprise queries this enables

• "Which new hires this month have overdue compliance training?" — HRIS MCP server (new hires) + LMS MCP server (training status).
• "What's the average time-to-productivity for Engineering hires vs. Sales hires?" — HRIS MCP server + LMS MCP server, aggregated and compared.
• "Show me all open IT tickets for employees who started in the last 30 days." — HRIS MCP server (filter by start date) + Ticketing MCP server (open tickets).

8. Security Checklist

MCP does not move or replicate data — it provides a standardized query interface to systems that already hold the data. But the interface itself must be locked down. Use this checklist before going to production: