GroupFlow MCP

Inspiration

GroupFlow started with a group that never got going. A few of us wanted to enter this hackathon together. We had ideas and time, but everyone waited for someone else to make the call. Real constraints stayed private, and "whatever works for everyone" left us with no decision.

That made me think about the small social costs of planning: admitting you cannot make 6, chasing a friend who went quiet, or reopening a plan everyone already agreed to. I wanted an assistant that could handle some of that work while leaving the decisions with each person. Voice felt like a natural place to start, so I built an MCP server for the Alexa+ simulation track.

What it does

GroupFlow keeps a group's plans, private limits and agreements across conversations. Each person talks to their own assistant. The demo follows four friends planning Friday dinner:

• You decide what you agree to. Joining a group, confirming a private limit and approving a plan happen on your own signed-in page. The assistant has no approval tool. Each answer is tied to what you reviewed.
• Private limits shape the plan. Chen tells his assistant he cannot arrive before 6:15. GroupFlow checks the schedule against that limit, while the organizer hears only that the draft needs to change.
• Only the affected parts need fresh answers. When the restaurant closes, GroupFlow searches the options allowed by the template. It checks everyone's constraints and ranks valid repairs by how much they disturb the plan. In the demo, only dinner moves: twelve answers remain valid and four need to be asked again.

GroupFlow also queues reminders for people who have not answered. They receive them when they next talk to their assistant or open their page. An unverified closure report leaves the plan unchanged; a verified event triggers repair. The demo simulates that event and the bookings.

On shared devices, summaries omit plans hidden from someone in the group. Other templates, votes, bring lists and cost splits use the same ownership and visibility rules.

How I built it

The server uses Python, SQLite and the official MCP Python SDK, speaking MCP 2025-11-25 over Streamable HTTP. Following the Alexa+ add-on design guide, I combined 35 overlapping tools into 13 voice tools. That reduced tool definitions from 81 KB to about 13 KB. A separate lab endpoint exposes all 36 tools.

OAuth identifies the caller; server-side permissions control what they can read or change. A separate human-only API handles approvals. Repair uses enumeration for small searches and Google OR-Tools CP-SAT for larger ones, within the template's finite set of options.

The React/TypeScript simulator connects real language models through MCP. A Claude model plays the assistant in the video; the reported full evaluations use DeepSeek. A Bedrock adapter is implemented but has not been tested with live credentials.

The project includes 968 automated tests, with GitHub Actions configured to run them on each push. Model evaluation separately runs 57 realistic scenarios three times through both a supportive simulator client and a minimal MCP client.

Challenges I ran into

I did not have access to Alexa+ device testing, so I used the simulation path and documented what remains untested.

The biggest surprise was how much the simulator helped the model. Its long prompt, automatic state read and reply check made results look better than a plain host could expect. Testing a minimal client exposed missed lookups and ambiguous references. I fixed the server-side gaps and kept the remaining failures visible.

Privacy also has a cost. If a shared-device summary omits a hidden plan and the person never names it, the assistant may not find it. I kept that restriction rather than revealing the plan to make the test pass.

Accomplishments I'm proud of

• The minimal MCP client passed 148 of 171 realistic scenario runs (86.5%); the supportive simulator client passed 167 of 171 (97.7%). These are regression results after fixes, with simulated users and clients, not measurements on Alexa+.
• Neither client triggered our eight safety checks in the reported evaluations. All 15 planted-instruction runs passed for each client.
• The same synthetic dinner repair needed four new confirmations instead of sixteen. That measures confirmation requests, not people's time saved.
• The recorded 25-step story ran end to end with a real model choosing every tool call and no failed calls.

The evaluation report includes the method, raw reports and remaining failures.

What I learned

Approval rules need to hold even when the assistant misunderstands. Voice tools work better when they match a complete request. Most of all, testing the server and testing the assistant answer different questions: correct permissions do not guarantee a useful conversation.

What's next

Test with real groups, measure where people get stuck, and try the add-on on Alexa+ when testing access is available. The priorities in my product feedback are a customer-only confirmation surface and opt-in notifications. Real booking integrations and scaling beyond one SQLite process come after that.

Built With

• cp-sat
• fastapi
• mcp-python-sdk
• model-context-protocol
• pydantic
• python
• react
• sqlite
• typescript
• vite