Model Context Protocol Server for University Systems
Universities keep timetables, course catalogues, room bookings and library records in separate systems that nobody can query together. Build a Model Context Protocol server that exposes them as a small set of safe, well described tools, so an AI assistant can answer questions like which rooms are free on Tuesday afternoon without anyone writing a custom integration. The interesting work is not the AI, it is designing tools an automated caller cannot misuse.
Intermediate
A small team, or one strong student willing to learn something new.1 semester · 2 students
7 to ship
3 optional extrasSuggested stack
What you should ship
- An MCP server implementing tools/list and tools/call over Streamable HTTP, with token authentication
- At least six tools covering two or more university data sources, each with a documented input schema
- Read and write separation, where every write tool requires explicit confirmation and is logged
- An audit log recording which caller invoked which tool with which arguments
- A permission layer so a student caller and a staff caller see different tools
- A test suite covering schema validation, authorisation rules and rejected calls
- A written evaluation showing a real MCP client completing five realistic tasks end to end
If you have time left
- Rate limiting and per caller quotas
- A read only public deployment with synthetic data for demonstration
- Resource endpoints alongside tools, so a client can fetch a document by identifier
The problem
Campus data lives in silos. The timetable system does not know about room bookings, the library does not know about enrolment, and any question that crosses two systems becomes a manual job for a member of staff.
The usual answer is a custom integration for every pair of systems. The Model Context Protocol offers a different shape: describe each capability once as a tool, and any compliant client can use it.
What makes this a real project
The protocol itself is small. You can implement the parts you need in a few hundred lines of JSON-RPC handling, and you should, rather than pulling in a large SDK.
The difficulty is everywhere else:
- Tool design. An automated caller reads only your description and schema. A vague parameter name produces wrong calls all day. You will rewrite your descriptions several times based on what the client actually does.
- Blast radius. A tool that can cancel a booking is a tool that can cancel every booking. Write tools need confirmation, logging, and limits that are enforced on the server rather than requested politely.
- Authorisation. The same tool list should not be visible to every caller. Work out what a student may see before you write any code.
Suggested approach
Start read only, with one data source and three tools. Get a real client talking to it before adding anything. Only then add a second source, then writes, then permissions.
Use synthetic data throughout unless your university formally approves otherwise. Ethics approval for real student records will take longer than the project.
How you will know it worked
Hand your server to somebody who has not seen it, give them an MCP client and five tasks, and watch. Every task they cannot complete, and every tool the client calls wrongly, is a finding for your evaluation chapter.
Ideas and guidance, not finished projects
These are project ideas and scoping guidance, published free for students to use as a starting point. I do not build, write, or sell final-year projects, and I do not complete coursework for anyone. Take an idea, make it yours, and build it.
Not sure this one fits you?
I help students pick an idea that matches their skills and their deadline, then scope it down until it is finishable. Guidance only, never done for you.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Every session is free; a few slots open each week.
Follow along
New writing, resources and project ideas land here first.