Project Ideas
A starting brief for an MCP capstone — a remote personal knowledge-base server, reachable from Claude and your own agents alike
Project Ideas
This is a brief, not a build guide
Like the other project briefs on this site, this page sets up one well-scoped project idea and leaves the building to you. Everything you need conceptually is in the Fundamentals track; this is where you'd point it.
The idea: a personal knowledge-base MCP server, hosted remotely, reachable everywhere
Why this, specifically: most MCP tutorials stop at a local stdio server running on your own laptop, talking to one client. That's a fine starting point, but it skips the parts that make MCP actually useful in practice: a server other people (or your other tools) can reach over the network, protected by real authorization, exposing both data and actions. Building a remote server for your own notes, documents, or a personal wiki exercises the whole protocol — resources, tools, transport, and auth — around something you'll actually keep using afterward.
The whole thing
Why this shape, specifically
Design choices worth making deliberately
Expose both resources and tools, not just one
RecommendedA server with only resources is a read-only library; a server with only tools skips MCP's application-controlled context model entirely. Building both — a resource for browsing/reading, a tool for searching and maybe writing — is what actually exercises the distinction the spec draws between them.
Go remote from the start
RecommendedA stdio server never has to think about authorization, reconnection, or serving more than one client at once — which means it never teaches you those parts of the protocol. Streamable HTTP plus real OAuth is more setup, but it's the shape almost every production MCP server actually takes.
Cap what a search result returns
Per the crash course's production warning, an unbounded tool result is a real failure mode, not a theoretical one. Decide a sensible result-size limit for the search tool before you connect it to anything, rather than discovering the problem when a host's context fills up.
Suggested stack
| Layer | Choice | Role |
|---|---|---|
| Server SDK | The official Python or TypeScript MCP SDK | Resource and tool registration, protocol handling |
| Resources | Your own notes/docs directory or database | Direct resources for known documents, a template for search-by-query |
| Tools | A search tool (and optionally a write tool) | The model-controlled half of the server |
| Transport | Streamable HTTP | Remote-reachable, matches the auth requirement |
| Auth | OAuth 2.1, Protected Resource Metadata | From Authorization & Security |
| Hosting | Any small always-on box or serverless platform that can hold an HTTP server | Where the server actually runs |
Stretch directions, if the base project goes well
- Add an elicitation flow (Elicitation) that confirms before a write tool overwrites an existing note.
- Wire the server into a custom agent from the Agents track or via smolagents'
MCPClient, so the same knowledge base is reachable both from Claude and from your own agent loop. - Add a Tasks extension (Extensions) if you extend the write tool into something long-running, like re-indexing the whole knowledge base — a durable handle instead of blocking the call.
Before you start
Work through What Is MCP? through Authorization & Security at minimum — the rest of the fundamentals track fills in as you hit each stage above. If a step above uses a term or technique you haven't seen yet, that's the signal for which fundamentals page to read next, not a sign you're missing something.
Glossary
Every MCP term and abbreviation used across the fundamentals track, grouped by theme — architecture, primitives, deprecated features, transport, auth, and extensions
MLOps Crash Course
All of MLOps on one page — serving, containers, orchestration, CI/CD, registries, monitoring, drift, caching, and the LLM-specific operational problems