Model Context Protocol Server for University Systems

The problem campus data creates for students and staff

Campus data lives in silos. The timetable system does not know about room bookings, the library does not know about enrolment, and the course catalogue is a PDF or an old portal. A question like "which labs with projectors are free on Tuesday afternoon" or "which of my courses have a quiz this week" crosses two systems and becomes a manual job for someone in the admin office.

The usual fix is a custom integration for every pair of systems, which never gets funded. The Model Context Protocol offers a different shape: describe each capability once as a tool with a schema, and any compliant AI client can use it. The risk is obvious too: an assistant that can book rooms can also cancel every booking if the server lets it.

What already exists and the gap

• Community course catalogue MCP servers (several are listed on the Glama MCP directory, including one for Georgia Tech's OSCAR schedule and one for NTNU course data) let an assistant search courses, prerequisites and schedules.
• Microsoft's MCP for Beginners curriculum and Anthropic's introductory MCP course teach the protocol with small example servers.
• University portals and student information systems hold the real data but expose it through web pages, not tools an assistant can call.

The existing campus servers are almost all read only, single source and single user. None of them answers the questions a university IT office would ask before switching one on: who can see which tool, what stops a write tool being misused, and where is the audit trail. That is the gap this project fills.

What you build

A server over two or more synthetic campus data sources with three roles:

• Student: read tools for timetable, free rooms, course details, library availability.
• Teacher: the above plus booking a room for an extra class and posting a schedule change.
• Administrator: reads the audit log and manages which roles see which tools.

Main flows: a client connects with a token, lists the tools its role allows, calls read tools freely, and must confirm before a write tool commits. Every call lands in the audit log.

The technically interesting part

The protocol itself is small; you can implement the JSON-RPC handling you need in a few hundred lines, and you should. The hard parts are design and safety:

• Tool design. An automated caller reads only your description and schema. A vague parameter name produces wrong calls all day. Keep a log of wrong calls and rewrite descriptions; show your supervisor the before and after.
• Blast radius. Write tools need server enforced limits (one booking per call, bookings only in the caller's department, rate limits), not polite instructions in the description. Use the protocol's tool annotations such as read only and destructive hints, but never rely on them for security.
• Authorisation. Filter the tool list per role and check the role again on every call, the same principle any API gateway follows.

How to evaluate it

• Task success: give a person who has not seen the project an MCP client and ten tasks. Report how many they complete, and every tool the client called wrongly.
• Safety tests: a list of at least 15 misuse attempts (wrong role, oversized arguments, repeated bookings, prompt text asking the client to cancel everything) and whether the server blocked each one.
• Description quality: measure the wrong call rate before and after rewriting tool descriptions.
• Latency: median tools/call time under realistic data size.

Suggested plan

1. Weeks 1 to 2: read the MCP specification, design the synthetic dataset, write tool descriptions on paper.
2. Weeks 3 to 5: one data source, three read tools, a real client talking to the server.
3. Weeks 6 to 8: second data source, roles, per role tool lists, authentication.
4. Weeks 9 to 10: write tools with confirmation, rate limits and audit log.
5. Weeks 11 to 14: evaluation with users and misuse tests, write up.

Path to a product

Your first customer is your own university IT or registrar office, as a pilot on a read only slice such as free rooms and the course catalogue. From there the realistic models are a paid integration and support contract per institution, or an open source core with a hosted version for smaller colleges that have no developers. Even as a portfolio piece, a secure MCP server with a published misuse evaluation is exactly what AI platform teams hire for.

Scope warning

Use synthetic data unless your university formally approves otherwise; ethics approval for real student records takes longer than the project. Do not build your own chat interface or train a model. Do not connect to live university systems in version one; mirror their shape instead.

Learn what you need on Sefism

• AI engineering roadmap : where tools, agents and MCP sit in a real AI product.
• AI engineering cheat sheet : quick reference for tool calling and agent patterns.
• Agents, RAG, MCP and LLMs: what is worth learning : context for why MCP skills matter.
• JSON Schema : every tool input is a schema; get this right first.
• OAuth 2 Simplified : the authorisation model behind remote MCP servers.
• AI Agents roadmap : how clients plan and call tools, so you can design for them.

Get help with this idea

The interesting work here is tool design and safety, not the AI. Tauseef can help you pick the right data sources, define the roles, and design a misuse evaluation your examiners will respect. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session