MCP Resource
What is an MCP resource?
An MCP resource is data exposed by an [MCP server](/glossary/mcp-server/) for a client to read through the Model Context Protocol. Each resource is identified by a URI. It might represent a file, database schema, documentation page, repository object, or other application-specific information.
Resources are primarily contextual data. They give the host something it can inspect, select, or provide to a model rather than an operation to execute.
How it works
A server that supports resources advertises that capability. An [MCP client](/glossary/mcp-client/) can list resources and read the contents of a selected URI. Servers may also expose resource templates for parameterized URIs and may support notifications when resources change.
Resource contents can be textual or binary. The host application decides how to present them. It might show a resource browser, let a user attach a resource, search available items, or automatically include selected content in model context.
MCP does not require every exposed resource to be placed into the context window. Selection, truncation, retrieval, and privacy rules remain application responsibilities.
Simple example
A repository server exposes repo://project/README.md and repo://project/schema.sql as resources. A coding assistant reads the schema resource when the user asks about database tables. No mutation occurs; the content is retrieved and used to inform the answer.
MCP resource versus MCP tool
An [MCP tool](/glossary/mcp-tool/) represents an operation that can be invoked, such as “search orders” or “update ticket.” A resource represents addressable data that can be read.
The boundary is about interaction semantics, not the underlying system. A database could expose its schema as a resource and a parameterized query as a tool. Reading a resource can still involve computation internally, but to the client it is a context-bearing object identified by a URI.
Why it matters
Resources make context sources discoverable without forcing every access pattern into a function call. They work well for information with identity that users or applications may browse, select, link, or revisit.
Builders should still apply authorization and minimize unnecessary context. A readable URI is not proof that every user should access it, and adding large resources can increase token use or displace more relevant context.