The project
Build an Android knowledge assistant backed by a read-only MCP integration with scoped access and auditable tool calls.
Prerequisites
Complete the six teaching modules and their exercises. Keep the design notes and failure cases: they form the starting evidence for this project.
Build in increments
1. What MCP is and what it is not
Understand the protocol before selecting a mobile integration. Apply the module decision to this project. Your checkpoint: You can explain why MCP connectivity does not imply authorization.
2. Discovery and capability negotiation
Build a client that learns supported operations instead of guessing. Apply the module decision to this project. Your checkpoint: Unknown capabilities produce a controlled result rather than arbitrary execution.
3. Transport and backend architecture
Choose a connection model that fits mobile constraints. Apply the module decision to this project. Your checkpoint: Your Android client remains independent from server transport internals.
4. Authorization and trust boundaries
Protect both identity and the data returned by tools. Apply the module decision to this project. Your checkpoint: Neither user text nor tool output can expand the granted authority.
5. Tool execution and result design
Keep tool calls observable and predictable. Apply the module decision to this project. Your checkpoint: A trace explains which operation ran, under whose authority and with what outcome.
6. Testing a mobile MCP feature
Verify the protocol boundary and the user experience together. Apply the module decision to this project. Your checkpoint: You can demonstrate a useful fallback without weakening the trust boundary.
Acceptance criteria
- Explain every host, client and server in the architecture
- Reject unauthorized tools and cross-user data access
- Handle unavailable servers without exposing tokens or raw errors
Evidence to submit
- A repository or reproducible design artifact with setup instructions and tested tool versions.
- A diagram showing components, data flow, authority and failure boundaries.
- An evaluation table with inputs, expected results, actual results and explanations of failures.
- A demonstration of the normal path and at least two relevant failure paths.
- A short decision record covering alternatives, known limitations and the next improvement.
Review rubric
| Dimension | Ready to demonstrate | Revisit when |
|---|---|---|
| Understanding | Explain each boundary and why it exists | You can only repeat framework terminology |
| Implementation | Reproduce the core behavior from a clean setup | Hidden local state is required |
| Reliability | Show bounded failures and useful recovery | The demo only works on the happy path |
| Evidence | Present observed outcomes and limitations | Success is inferred from a generated answer |
| Ownership | Modify a requirement and explain the consequences | You cannot adapt the implementation independently |
Do not treat a completed reading checklist as proof of project readiness. Revisit any module whose checkpoint you cannot demonstrate.