UniTrack

Final-year project supervision, minus the busywork, now with an agent that does the work so you focus on supervising.

Comment

Inspiration

I built UniTrack a while back as a final-year academic project management platform for my department. It handles the whole workflow between the departmental admin (who assign supervisors and set academic sessions), supervisors (who review and approve or reject student chapter submissions), and students (who submit their chapters for review). It's a real system, built to remove the difficult manual project supervision process in universities.

What got me into this hackathon was a pretty simple realization: a lot of the actual work in that system isn't clicking buttons, it's stuff like a supervisor trying to remember what feedback they gave to a student they gave three weeks ago and having to read through the entire document to see if the student's submission addressed the feedback they gave, or an admin trying to match a student to the right supervisor based on... honestly, mostly vibes and memory. None of that is a UI problem. It's a "nobody has time to manually cross-reference this" problem. That felt like exactly the kind of thing an agent should be good at, if it could actually understand the app instead of just clicking around it.

What it does

UniTrack now lets an AI agent inside ChatGPT's browser, call real, structured tools directly on the app, instead of guessing its way through the UI. Depending on who's logged in, the agent can:

For supervisors: scan all feedback a supervisor has given across their students and show recurring patterns to give insights in to what their students are struggling with ("you've flagged citation formatting in 4 of 5 submissions this session"), or compare two versions of a resubmitted chapter and explain in plain language what actually changed and whether previous feedback was covered by student.

For admins: suggest which students should be assigned to a supervisor , based on each supervisor's stated expertise and each student's stated interests, with real reasoning attached instead of the admin just randomly assigning (this is important because supervisors get to supervise only projects within their expertise and students get the best out of the process). Every risky action: actually assigning a supervisor, actually approving a submission, still requires a human to confirm it in the real UI. The agent suggests and summarizes; people decide.

How we built it

The core of it is simpler than it sounds. My existing Django REST Framework backend barely changed. WebMCP tools live entirely on the frontend. I registered them using document.modelContext.registerTool() right inside my React components, and each tool's execute() function just calls the same API endpoints my frontend already used. No new backend framework, no separate MCP server. Django keeps serving JSON like it always did; the tool layer is just a new way of calling it.

I tested tools locally first using the Model Context Tool Inspector extension in Chrome, before ever touching ChatGPT. That gave me a fast way to check a tool was registered correctly and returning the right shape of data. Once that worked, I moved to testing the real thing: opening the app inside ChatGPT desktop's built-in browser and asking it natural-language questions to see if it actually called the right tool.

Challenges we ran into

Time was the big one. I had a handful of days, not weeks. I had to be honest with myself about scope more than once: I really wanted to rebuild the whole frontend cleaner at one point, and had to talk myself out of it, because a working demo was more important with a deadline like this.

I also ran into a real technical snag: WebMCP tools only get discovered if they're registered on the top-level page, not inside an iframe. I had to actually go check my own app's structure to make sure nothing was quietly broken by that before I got too far into building.

And honestly, the trickiest part wasn't the WebMCP API itself, it was making the agent's suggestions actually mean something instead of feeling generic. Anyone can build a tool that technically returns data. Making the reasoning specific enough to feel genuinely useful, took real iteration on the seed data and the tool logic.

Accomplishments that we're proud of

I'm proud that this isn't a toy demo app built just for the hackathon, it's a layer on top of a platform that solves a real problem in our universities. I'm also proud of keeping the human-in-the-loop boundary honest: nothing the agent suggests silently becomes real without a person clicking confirm, which felt like the right call the whole way through, not just something I added to check a box.

I'm also proud of the chapter-diff tool: the one that get's the agent to explain "here's what changed, and here's what you already flagged that's still unresolved" is a small thing on paper, but it's exactly the kind of busywork that eats a supervisor's actual time, and watching it work correctly was genuinely satisfying.

What we learned

Going in, I assumed WebMCP was some heavy thing. It turned out to be much simpler and much more useful than I expected: a website just says "here's a function you can call, here's what it needs, here's what it returns," instead of an agent guessing its way through a UI by clicking things and hoping for the best.

I also learned that ChatGPT treats every tool call and its results as untrusted content by default, which genuinely changed how I thought about which actions should be automatic versus which ones need a human to confirm — that wasn't just a security afterthought, it shaped the actual design of the tools.

What's next for UniTrack

Right now, everything the agent can do lives inside one supervisor's or one admin's session which is genuinely useful, but it's still one person and their agent, working alone. The next real step is making the agents themselves coordinate. Picture a student's agent and their supervisor's agent actually negotiating a review deadline or a meeting slot directly: the student's agent proposes times, the supervisor's agent checks their real calendar and workload, and both humans just confirm at the end instead of doing the back-and-forth themselves. That's a genuinely different kind of "agent-native" than anything I built this week, and it's the direction that excites me most.

I'd also want to move the supervisor-matching logic off simple tag overlap and toward something that actually understands a lecturer's real research background: their publications, past supervised topics, the language they use to describe their own work, rather than relying on whatever keywords they happened to type into a profile field. Self-reported tags are a fine starting point, but they're not how expertise actually works.

And I'd want to stop building this in isolation. UniTrack is currently scoped to one department, but final-year project supervision is a near-universal structure across departments and universities - admin, supervisor, student, the same shape everywhere. If this genuinely saves supervisors and admins real time, the honest next step is putting it in front of an actual department for a full academic session, not just testing it myself, and seeing whether it holds up against real workloads, real deadlines, and real people who didn't build the thing and have no reason to be generous with it.

Note

UniTrack existed before this hackathon as a deployed final-year project management platform.

It may be seen as a new repository because I had to merge the frontend and backend in to a single repo (they were separate before) for the purpose of the hackathon, but the commit history is intact.

During the submission period, I added a WebMCP layer on top of the existing app: registered client-side tools (document.modelContext.registerTool()) that let an AI agent call real, structured functions directly which are a supervisor-facing tool that surfaces recurring feedback patterns across all their students, a tool that checks two versions of a resubmitted chapter and explains what changed, and an admin-facing tool that suggests supervisor assignments based on declared expertise and student interests and a student facing tool that helps them generate practice defense questions. I also added a few new backend endpoints and two new profile fields (lecturer expertise, student interests) specifically to support this matching logic, none of which existed before this hackathon.

Built With

Share this project:

Updates

Submission history