How an Engineer Uses MCP to Track Professional Goals Without Weekly Dread

Oren is a senior engineer at a mid-sized SaaS company. He has good intentions about professional development but a track record of goal-tracking systems that work for two or three weeks, then quietly collapse.

The pattern is familiar: enthusiastic setup, consistent usage for a short sprint, then a busy week that breaks the habit, then the system sitting idle while guilt accumulates. Oren had tried Notion-based OKR tracking, daily journaling, weekly review templates, and a handful of purpose-built apps. Each failed at roughly the same moment — the point where the preparation required to run a useful review exceeded his available Friday afternoon energy.

When Oren read about MCP in late 2024, he was skeptical. More infrastructure, more configuration, more things to break. But the core promise — that the AI could retrieve his data instead of requiring him to summarize it — addressed exactly the step that had always killed his reviews.

What followed was three distinct iterations. This is an account of what happened in each, and what made the third iteration different.

Baseline: What Oren’s Goal Tracking Looked Like Before

Oren had three active professional goals entering Q4 2024:

1. Ship the side project: A developer tools app he had been building intermittently for 18 months. Goal: reach public beta by end of year.
2. Consistent open source contributions: At least one meaningful PR or issue per week to projects he used professionally.
3. Learn Rust: Write functional Rust code for at least 30 minutes, three times per week.

He had these written in a Notion page. He had a habit tracker app on his phone with streaks for the Rust goal. He had calendar blocks labeled “side project” on Tuesday and Thursday evenings.

On paper, the system was adequate. In practice, the weekly review — when it happened — consisted of Oren glancing at the Notion page, feeling vague guilt about the side project, updating the Rust streak count, and writing a two-sentence reflection that said something like “need to be more consistent.”

The reviews were honest but not useful. They named the problem without diagnosing it.

Version 1: Too Much at Once

Oren spent a Saturday in late October setting up MCP. He configured four servers simultaneously: Google Calendar, Notion, GitHub, and a task manager integration. He was thorough, followed documentation carefully, and had all four connected by the afternoon.

The first review conversation was long and detailed. Claude synthesized data from all four sources, produced a multi-page analysis, and identified seventeen things Oren could improve about his goal-tracking approach.

Oren read the first three items and closed the tab.

The problem was not the quality of the analysis. The problem was that Oren had fed the AI inconsistent data and the AI had faithfully analyzed all of it. His calendar blocks said he worked on the side project Tuesday and Thursday evenings. His GitHub data showed commits on random weekday mornings, rarely on Tuesday or Thursday. His task manager had tasks marked done that he knew he had not completed. His Notion goal page referenced a version of the project that no longer reflected what he was actually building.

The AI synthesized these contradictions earnestly. The output was detailed, accurate to the data, and profoundly unhelpful.

Lesson from Version 1: Do not connect data sources you have not verified are accurate. The AI amplifies what is actually in your systems, not what you intend to be in your systems.

Version 2: Calendar and GitHub Only

Oren stripped back to two servers: Google Calendar and GitHub. He also spent an hour cleaning up:

• Renamed all calendar blocks to be specific: “side project — auth flow” instead of “side project”
• Archived the outdated Notion goal page and wrote a clean, single-page replacement
• Accepted that the task manager was not a reliable data source and removed it from the equation

The second setup took 40 minutes. The first real review, one week later, ran off two sources only.

The output was immediately more useful. Claude pulled his GitHub commits for the week — three commits to the side project on different days than his calendar blocks. This was actually informative: Oren worked on the project opportunistically during the day, not in the planned evening blocks. The evening blocks mostly disappeared to fatigue.

That insight — calendar intent versus commit-history reality — was something Oren had suspected but not confirmed. His blocks were scheduled for the wrong time of day. He worked better in morning sessions, which his commit timestamps confirmed.

He also noticed the open source goal had produced zero activity for two consecutive weeks. The calendar had no blocks for it. He had been telling himself he would do it opportunistically, but the commit history showed he had not.

Lesson from Version 2: Even a minimal two-server setup produces more accurate insight than self-report, provided the data is clean. The calendar vs. GitHub divergence was visible only because actual commit times were being compared to scheduled blocks.

Version 3: Adding Beyond Time for Structured Progress

The Version 2 system worked but lacked structured progress data. GitHub commits were evidence of activity, not evidence of progress. Oren could commit ten small fixes in a week and be no closer to beta than when he started.

He added Beyond Time as a goal tracker with MCP support, setting up three goals with explicit progress metrics: beta launch (percentage of features complete), OSS contributions (weekly count), Rust practice (session count per week). This gave Claude a structured quantitative layer that commit data alone could not provide.

The three-source weekly review — Calendar (time reality), GitHub (code activity), Beyond Time (progress metrics) — now ran in about 12 minutes. Claude pulled all three sources at the start of the conversation, produced a brief synthesis, and ended with one specific recommendation.

A representative output:

Week of November 11–17:

Side project: Calendar shows 3 morning blocks (Mon, Wed, Thu). 
GitHub shows 7 commits, mostly to the auth module. 
Progress tracker: 68% complete, up from 61% last week. 
On track for beta if this pace continues through November.

OSS contributions: 0 commits to external repos. No calendar blocks 
scheduled for this goal. This is the second consecutive week at zero.

Rust practice: 2 sessions logged in tracker vs. 3-per-week target. 
Calendar shows one block that appears in Rust commits. Second session 
not on calendar — likely opportunistic. One session missed entirely.

Recommendation: The OSS goal has no time on the calendar. 
Either schedule a 30-minute block for it on Wednesday mornings, 
or formally defer this goal to Q1.

Oren read this in two minutes and made one decision: he moved the OSS goal to Q1 and freed up the mental overhead. That decision had been pending for six weeks. The review made it unavoidable.

What Changed in the Stable State

By December, Oren’s Friday review took 10–12 minutes. The prep work before the conversation: zero. He opened Claude Desktop, ran the review prompt (saved as a template), read the output, made one decision.

The system had not made him more productive in a granular sense. He still worked roughly the same hours. But three things changed:

He stopped lying to himself about the open source goal. The calendar had no blocks for it. The commit history confirmed zero activity. Faced with that data two weeks running, he made a real decision instead of a deferred intention.

He shifted his side project blocks to mornings. The commit timestamp data made the pattern obvious. Switching from Tuesday/Thursday evenings to Monday/Wednesday/Friday mornings increased both adherence and output quality.

The review stopped feeling like an obligation. When gathering context requires 20 minutes, starting a review requires willpower. When gathering context is automated, starting a review requires opening a tab.

The Broader Lesson

Oren’s case is not unusual. The failure mode in Version 1 — connecting too many sources before verifying data quality — is the most common mistake in MCP goal tracking. The recovery, in Version 2, was not more technology. It was better data in fewer sources.

Version 3 added structure, not complexity. The third source (a purpose-built goal tracker) gave Claude a clean quantitative layer that qualitative sources could not provide. The addition was worth it because the foundation was already solid.

The MCP Goal Stack works as a compounding system. Good data leads to useful analysis, which leads to better decisions, which leads to better data. The compounding only starts when the foundation is clean.

Your action for today: If you have been tracking a goal inconsistently, pull up the last month of your calendar and count how many hours you actually blocked for it. That number — before any AI integration — is the honest starting point.

Related: The Complete Guide to MCP Integration for Goal Tracking · The MCP Goal Tracking Framework · Why MCP Goal Tracking Can Overcomplicate

Tags: MCP case study, goal tracking, AI planning, engineer productivity, Beyond Time