Inspiration
42 ToDo began with a simple frustration: capturing a thought shouldn't require stopping what you're doing, opening an app, and typing.
I wanted to capture tasks naturally through conversation, particularly while driving or working hands-free.
As I started using multiple AI assistants, I recognized another opportunity: create a lightweight task system that works independently of any particular AI provider.
But there was an important engineering requirement. Managing everyday tasks shouldn't require an expensive, state-of-the-art AI model.
If the system is going to be practical for everyday use, it needs to work with affordable models that can understand a request, select the correct tool, and complete the operation reliably.
That became a central design objective for the 42 ToDo MCP server.
What it does
42 ToDo MCP connects compatible AI assistants to a persistent task-management system through the Model Context Protocol.
Users can conversationally create, retrieve, update, schedule, complete, and organize tasks.
The server is specifically designed to make these operations understandable and reliable for smaller, lower-cost language models, including GPT-4o mini.
Rather than relying on a powerful model to interpret ambiguous tool definitions, the MCP interface emphasizes clear operations, structured inputs, predictable responses, and testable behavior.
The result is a practical task-management integration that can run through cost-conscious AI configurations while remaining compatible with more capable assistants.
The same task system can be accessed through multiple supported AI clients, keeping commitments independent of any single model provider.
How I built it
I built a dedicated TypeScript and Node.js MCP server that exposes 42 ToDo's existing task-management API through standardized tools.
The implementation focuses on three engineering priorities:
1. Small-model compatibility
I designed the MCP tool interface around clear descriptions, explicit arguments, predictable schemas, and consistent responses.
This reduces ambiguity when smaller models decide which tool to call and how to populate its arguments.
GPT-4o mini was used in the hackathon demonstration to exercise the server through a conversational interface, including a text-based simulation of voice interaction.
2. Reliable, testable operations
The server separates MCP protocol handling from the underlying task-management business logic.
It supports local testing, MCP Inspector, and real client integration through Claude Code. Automated contract testing helps maintain consistent tool definitions and behavior.
The goal is to make ordinary task-management requests reliable without depending on expensive model reasoning to compensate for unclear tool interfaces.
3. Secure, interoperable authentication
The underlying 42 ToDo platform uses AWS infrastructure and Amazon Cognito.
MCP client interoperability required additional OAuth support, including Dynamic Client Registration (DCR) and Client ID Metadata Documents (CIMD).
This allows the MCP integration to work with supported clients while preserving authentication and authorization boundaries.
Challenges
One of the most interesting challenges was designing tools for smaller language models.
A powerful model can sometimes work around unclear descriptions, infer missing information, or recover from ambiguous interfaces. Smaller models have less room for that.
That made tool naming, parameter descriptions, schema consistency, error handling, and predictable operations important engineering decisions.
I also had to address differences between MCP clients, OAuth registration expectations, and the authentication capabilities provided by Amazon Cognito.
Additional challenges included HTTP transport behavior, hosted deployment, and maintaining consistent tool contracts across different execution environments.
These problems and their workarounds are documented in the project's friction log.
What I learned
Good tool design can reduce how much intelligence an application needs from the model.
Instead of assuming every task requires a powerful and expensive model, developers can make the interface easier for smaller models to use.
Clear tool contracts, constrained inputs, predictable outputs, and meaningful error messages can improve reliability while allowing more economical model choices.
I also learned that MCP provides a useful boundary between AI assistants and application logic. The assistant handles natural language, while the server exposes controlled capabilities and the backend remains responsible for persistent data and business rules.
The project reinforced that AI interoperability, affordability, and reliability need to be designed together.
What's next
My primary goal is to bring this experience to Alexa+, enabling people to capture and manage tasks naturally through Alexa-enabled devices.
The MCP server provides a working integration foundation, although direct Alexa+ integration has not yet been demonstrated.
I also want to continue improving compatibility with smaller, inexpensive models and expand automated testing across model and client combinations.
Longer term, 42 ToDo could provide a shared place for work assigned to people and AI agents, without tying that work to any one assistant.
The goal is simple: make conversational task management useful, reliable, and affordable enough for everyday life.
Built With
- amazon-api-gateway
- amazon-cloudfront
- amazon-cloudwatch
- amazon-cognito
- amazon-dynamodb
- amazon-route-53
- amazon-ses
- amazon-sns
- android
- aws-cloudformation
- aws-lambda
- dart
- fire-tv
- flutter
- google-play-billing
- javascript
- model-context-protocol
- node.js
- react
- react-router
- sqlite
- typescript
- vite
Log in or sign up for Devpost to join the conversation.