Resources are the read-only side of MCP. They model anything that has a stable identity and can be fetched: a file on disk, a row in a database, a documentation page, a snapshot of memory state. Each resource has a URI (its name on the wire), a mime type, optional annotations, and a piece of content that is either text or binary.
The protocol exposes three resource methods: resources/list returns the available resources, resources/read returns one resource's content by URI, and resources/subscribe (when the server advertises it) lets the client be notified when a specific resource changes. Subscribers are the foundation for live-data UIs in hosts that want to keep a panel up-to-date.
The right mental model: Resources are what the host can read without asking the user. They are safe by design — no side effects, no state mutations, no irreversible operations. That is why hosts can list and pre-fetch them aggressively without prompting for confirmation.
Common pattern: a Postgres MCP server exposes one resource per table (URI like postgres:///orders), a filesystem server exposes a resource per allowed path, a docs server exposes a resource per page. Tools mutate; Resources just sit there ready to be read.