StudyPulse: Building a Student Study Planner with MCP and Google Cloud

I built a study planner that tracks syllabus completion, sends progress reports through Gmail, and adds exams to Google Calendar without exposing Google tokens to the web app.

The Problem

Most study apps track activity — "you studied for 3 hours." They don't tell you if you're ready for an exam. A student can spend weeks in an app and still not know if they've actually finished the syllabus.

I was helping a friend study for a competitive exam. She had apps for notes, for questions, for schedules. None of them answered: "Out of everything I need to know, how much do I actually know right now?"

The Solution: One Number, One List

StudyPulse is a web app that does one thing well: it shows you what fraction of your syllabus is done, and what you should study next. You add subjects, break them into topics, tick them off. The app calculates real progress — accounting for partial work — and lets you mail a report to a parent or mentor from your own Gmail.

The Architecture: Why MCP Matters

The main architectural decision was to keep Google OAuth tokens outside the web application. Instead of allowing the web app to communicate directly with Gmail and Google Calendar, all Google-related operations go through a separate MCP server.

Here's where it gets interesting. The app could call Gmail and Google Calendar directly. Instead, it doesn't. Gmail and Calendar talk to a Model Context Protocol server — a standalone service that owns the Google tokens and exposes tools.

StudyPulse Web App
        |
        | HTTPS + shared secret
        v
StudyPulse MCP Server
        |
        | Google OAuth tokens
        v
Gmail API + Google Calendar API

The web app → (HTTPS + shared secret) → MCP server → (Google OAuth tokens) → Gmail + Calendar

Why? Three reasons:

1. Token isolation: The web app never sees a Google token. No token leaks from a web app vulnerability.
2. Reusable tools: The same nine MCP tools work from the web, from a cron job, or from Claude Desktop. One integration, many clients.
3. Clear separation of concerns: Google plumbing is someone else's problem. The web app is just business logic.

How We Set It Up: Google Cloud Console

Google Cloud Console is used to configure Gmail, Google Calendar, OAuth permissions, test users, and application credentials.

The Google part is straightforward:

1. Create a project in Google Cloud Console
2. Enable two APIs: Gmail API, Google Calendar API (both free)
3. OAuth consent screen: mark it External, add your test users
4. Add four scopes to the consent screen: gmail.send, gmail.compose, calendar.events, userinfo.email
5. Create an OAuth client (Web application type), add your redirect URI: http://localhost:3000/api/google/oauth/callback

The app handles the OAuth flow from there. Students sign in with a magic link to StudyPulse, then click "Connect Google" in Settings. They consent once — refresh tokens let them stay connected.

The Tech Stack

• Web: Next.js 15, React 19, Supabase (auth + database)
• MCP Server: Node.js + @modelcontextprotocol/sdk
• APIs: Gmail, Google Calendar, Google OAuth
• Hosting: Vercel (web), any Node host (MCP server)
• Database: PostgreSQL with row-level security

server.registerTool(
  'calendar_create_event',
  { description: 'Create a student exam event' },
  async (args) => ok(await createEvent(await clientForUser(args.userId), args)),
);

What Surprised Us

The project taught us that integration complexity is often less about writing API calls and more about handling authentication, security, and data ownership correctly.

1. OAuth testing is clunky: Manually connecting/reconnecting Google accounts for each test. In production, testing mode refresh tokens expire every 7 days, so students have to reconnect weekly. That's by design for security, but it's a friction point.

2. MCP was the right call: Isolating tokens forced us to think clearly about the API boundary. The resulting tool set (study_progress_snapshot, gmail_send_report, calendar_create_event) works outside the web app too — Claude Desktop clients can use the same server.

3. Row-level security matters: Supabase RLS meant that even if someone leaked the anon key, they could only see their own data. That confidence let us build fast.

What's Next

StudyPulse is live for 5 test students. Next: real deployment (Vercel + Render), email verification (CASA assessment if we use restricted Gmail scopes beyond testing), and mobile app (Flutter).

Try It

• Live demo: [https://drive.google.com/file/d/1Kwl3nrJzNpJx28anfxd6f5XCo7KX235Z/view?usp=drive_link]
• GitHub: [https://github.com/Rajnandini-Patil-30/studypulse]
• Try locally: Instructions in the README

---

Key Takeaway

You don't need to choose between security and developer velocity. An MCP server costs almost nothing to build, buys you token isolation, and lets the same tools work across clients. For student-facing apps handling sensitive data, that's worth the small architectural lift.

---

Questions? Drop them in the comments.