Complete the project-notes server

Your final repository should contain:

• src/notes.ts with safe practice data
• src/server.ts with search_notes, get_note, notes://catalog, and review_project
• src/index.ts for stdio
• src/worker.ts for remote HTTP
• README.md, TESTING.md, and SECURITY.md

The project now has one capability factory and two serving lifecycles:

createServer()
  ├─ serveStdio()          one instance per connection
  └─ createMcpHandler()    one instance per HTTP request

Both expose the same two tools, one resource, and one prompt. Durable data and caller identity stay outside the McpServer instance.

Run the final checks:

npm run check
npm ls @modelcontextprotocol/server

Then run the complete Inspector matrix against stdio, local HTTP, and deployed HTTP. Verify the local host configuration from a clean terminal and the deployed endpoint from a separate client session.

Read the final capability descriptions once more. A person should understand what each item does and whether it changes anything without opening the source.

Check the evidence, not only the happy path:

• invalid inputs never reach handlers
• absent notes are errors, not empty success
• structured output matches its schema
• stdout contains only protocol messages
• the HTTP boundary rejects unexpected paths and callers
• logs contain no note bodies or credentials
• retrieved text remains untrusted data

Finish the README with three direct sentences: what the server makes possible, what access it has, and what must change before connecting private production data.

For this course project, the last sentence should mention authorization, least-privilege backend credentials, rate limits, and a repeated security review.

You now have a small MCP server whose usefulness, protocol surface, and security boundary can all be explained.