WebMCP Course Planner

A course planner where student and AI work from one live WebMCP state, so the AI builds valid schedules, adapts to manual edits, and leaves registration to the student.

Comment

Inspiration

Course planning looks simple until you actually try to make everything fit.

A student might want to stay under 15 credits, avoid early classes, keep Friday free, make progress toward their degree, and still protect time for work. One small change can make a schedule that looked fine stop working.

That made me think about how an AI agent could help with this kind of problem.

The obvious approach is to let the agent look at the webpage, figure out which buttons to use, click around, and check whether the result looks right. But that still leaves the agent guessing how the interface works.

WebMCP suggested a different idea: what if the website could give the agent a structured way to read and work with the same live state the human is already using?

That became WebMCP Course Planner.

I wanted a small but convincing example of a future where a human and an AI agent don't take turns controlling a webpage, but collaborate through it. Human changes the website, the live state changes, the AI sees that new state through WebMCP, and the work continues.

What it does

WebMCP Course Planner is a fictional Biology semester-planning application where a student and an AI agent work on the same live course plan.

The student gets a normal visual interface where they can choose courses, review a weekly timetable, set a maximum credit limit, avoid 8 AM classes, keep Friday free, block Tuesday from 11:00 AM to 12:00 PM, review conflicts, and make the final fictional registration decision.

The website also exposes WebMCP tools that let an AI agent read the current planner state and update the selected courses.

The interesting part happens when the human changes something directly. In the demo, the agent first creates a schedule containing STAT 210. Then I manually block Tuesday at 11 AM inside the planner. I don't tell the agent what I changed.

When the agent reads the planner again, it sees the new blocked time and the conflict with STAT 210. It can explain the trade-off and help build a new plan while keeping the preference I set myself.

The human and the agent aren't working from separate copies of the data. They're working with one live planner state.

How I built it

The application is built with React 19, TypeScript, Vite, the WebMCP Imperative API, and Vercel.

I kept the WebMCP surface very small. The production application exposes two tools.

get_course_plan is the read-only tool. It gives the agent the current planning context: the student's preferences, selected courses, credit total, remaining requirements, available catalog information, conflicts, and whether the plan is ready for review. It reads the latest planner state, so if the student changes a preference directly in the webpage, the next call sees it.

set_course_plan is the write tool. It lets the agent replace the selected course set using valid course IDs. Its authority is deliberately limited: the agent can change the course selection, but it cannot change the student's scheduling preferences and it cannot perform the final registration confirmation.

Both the visual interface and the WebMCP tools connect to the same canonical React state. When the human changes something, the tools see it. When the agent changes something, React renders the result for the human to inspect.

The planner calculates conflicts deterministically in application code rather than asking the language model to decide whether a schedule is valid.

Challenges I ran into

The biggest challenge was deciding what not to build.

A university registration system gets enormous fast. I could have added prerequisites, live seat availability, authentication, registration windows, student databases, full degree audits, multiple semesters, and real registrar integrations. Those are interesting, but they would have made the most important WebMCP interaction harder to demonstrate reliably.

So I kept coming back to one question: what is the smallest workflow that shows why WebMCP matters?

That led to one student, one semester, one planner state, one read tool, one bounded write tool, and one strong human edit.

The other challenge was deciding how much authority the AI should have. I didn't want a demo where the agent simply takes over the website. The student owns their preferences. The agent can read them and adapt the selected courses around them, but it can't quietly rewrite what the student wants. Final confirmation stays with the human. Finding that boundary made the project better.

Accomplishments that I'm proud of

The thing I'm most proud of in this project is Miu.

As AI systems get more capable, they also get harder for normal users to follow. A student might ask ChatGPT to fix a schedule, see the timetable change, and know that something happened without understanding what the agent did in between. I wanted to make that interaction visible.

Miu is a small on-page companion that gives WebMCP activity a personality. She isn't another AI agent and she doesn't hold her own state. She reacts to real events happening between ChatGPT, the WebMCP tools, and the planner.

When ChatGPT reads the current planner through get_course_plan, Miu reacts as if she's checking the schedule. When set_course_plan updates the selected courses, she reacts to the planning work. When a human edit creates a conflict, her expression changes. When the plan becomes ready again, she responds to that too.

So instead of an invisible tool call happening somewhere behind the interface, the student gets a visual cue for the current stage of the interaction.

Without Miu, the workflow feels like: "AI, fix my schedule," and then something changes. With Miu, the student can follow it: the agent is reading, something changed, there's a conflict, the agent is adapting, the plan is ready.

That mattered to me because I don't want agentic software to get less understandable as it gets more powerful. I want the human to stay aware of what is happening.

I'm also proud of the smaller technical moment underneath all of this. I can change Tuesday at 11 AM from available to blocked without telling the AI what I changed. The next time ChatGPT reads the planner, it finds the newer state and reacts to the STAT 210 conflict.

That's where the project stopped feeling like an AI operating a website and started feeling like a human and an agent sharing a workspace. And the whole thing only needs two focused WebMCP tools: read, act, human edits, read again, adapt, human reviews.

Miu makes that invisible loop visible.

What I learned

Building for AI agents is not the same as giving an AI more control. Clear boundaries can make an agent more useful. A small tool with one responsibility is easier to understand, test, and trust than a generic tool that can manipulate everything.

I also learned how much shared state matters. The most interesting part of WebMCP for me wasn't structured function calling. It was that the website can stay the source of truth while both the human and the agent work against that same current state.

That creates a different relationship between an agent and a web application. The human doesn't have to stop using the interface because an agent is helping, and the agent doesn't have to pretend to be a human clicking through it.

What's next for WebMCP Course Planner

For this challenge I kept the project focused on one semester-planning workflow. There are plenty of directions it could grow: prerequisite checking, live seat availability, persistent student profiles, multi-semester planning, richer degree requirements, and eventually integrations with real university systems.

I'd want to add those carefully rather than just increase the number of tools. The principle I want to keep is the one that shaped this version: the website stays the source of truth, the agent gets clear and bounded capabilities, and the human has a real role in the final outcome.

This is a small experiment, but building it made the future of the web feel more concrete to me. Instead of asking whether AI agents will replace web interfaces, I think the better question is what humans and agents can do when the web is designed for both.

Main changes: removed the mechanical bolding and the dramatic one-sentence-per-paragraph rhythm, cut lines that only existed to say the idea mattered ("That moment is the heart of the project", "Finding that boundary made the project much stronger" trimmed), joined the fragmented bullet list into prose, and dropped words like "genuinely", "intentionally", "completely", and "entirely" where they were just emphasis.

Built With

Share this project:

Updates

Submission history