Why architecture matters here
Resource design shapes the user experience. Too many resources without templates overwhelm the host UI. Missing subscribe means users see stale context. Bad access control leaks data.
The architecture matters because resources sit between the underlying system (a filesystem, a database, an issue tracker) and the LLM host — you must expose enough to be useful without exposing too much.
With the pieces mapped, you can decide what to expose, how to structure URIs, and where to invest in caching + subscription.
The architecture: every piece explained
The top strip is the API surface. MCP server declares available resources during capability negotiation. URI templates (RFC 6570) let the server describe parameterized resources (file://project/{path}). resources/list returns paged enumeration. resources/read fetches by URI.
The middle row is the content + updates. Content types support text, binary blobs, and images. Subscribe registers interest in specific URIs. notifications/resources/updated is a server-push message when a subscribed resource changes. Access control is capability + scope-based.
The lower rows are practical. Caching layer uses ETag or timestamps for conditional fetch. Client UI lets users pick resources or auto-attach relevant ones. Ops covers size limits, rate limits, and audit.
End-to-end flow
End-to-end: an MCP server exposes a project's files and open issues. Client calls resources/list; server returns first page. User picks "README.md"; client calls resources/read; content flows. User also subscribes to "issues/1234"; when the issue changes, server pushes an updated notification. Client shows the updated summary. Access control ensures the user cannot read files outside her project. Audit trail records every read.