【続編】MCPはToolsだけじゃない！Resources・Promptsまで実装して理解するチュートリアル This sequel tutorial builds on a previous MCP Tools guide by covering Resources and Prompt…

The Model Context Protocol (MCP) is often introduced through its Tools capability, but that is only one of three server-side primitives the specification defines. This sequel tutorial, following an earlier guide focused on Tools, walks through implementing the remaining two, Resources and Prompts, using a hands-on, code-first approach. For developers moving beyond a first proof of concept, understanding all three primitives matters because it determines how much context and control an MCP server can actually offer to a connected model or application.

MCP, introduced by Anthropic in late 2024, is an open standard that aims to give large language model applications a consistent way to connect to external data and functionality. It uses a client-server architecture in which a host application, such as an AI assistant or an integrated development environment, runs one or more MCP clients that talk to MCP servers. Communication is based on JSON-RPC 2.0, typically over standard input/output for local servers or over HTTP with server-sent events for remote ones. Rather than every application inventing its own integration format, MCP provides a shared protocol, which is why it is frequently described as an attempt to standardize the connection layer between models and the outside world.

A central concept the article reinforces is that the three primitives differ not only in what they do but in who controls them. Tools are model-controlled: the language model decides when to invoke a function to take an action or fetch computed results. Resources are application-controlled: they expose data, such as file contents, database records, or API responses, that the host application can choose to load into context. Prompts are user-controlled: they are predefined templates a user typically selects deliberately, often surfaced in the interface as slash commands or menu items. Grasping this distinction helps explain why a well-designed server does not simply expose everything as a Tool.

For Resources, the tutorial demonstrates how a server advertises available data through unique URIs and returns content when a client requests it. Resources can be static, such as a fixed document, or dynamic through URI templates that accept parameters, allowing a single handler to serve many addressable items. Because Resources are meant to supply context rather than trigger side effects, they are generally treated as read-oriented, and the host decides how and when to include them in a model's working context. This makes them well suited to grounding responses in specific files or records without requiring the model to call a function each time.

For Prompts, the walkthrough shows how a server can register reusable templates that accept arguments and expand into structured messages. This lets teams package proven prompting patterns, for example a code-review request or a summarization workflow, so users can invoke them consistently instead of retyping instructions. Because Prompts are surfaced to the user rather than silently chosen by the model, they fit naturally into interfaces where a person is steering the interaction.

The practical value of the sequel is that it ties these pieces together in working code, most likely using one of the official SDKs, which are available for languages including Python and TypeScript. These SDKs handle much of the protocol boilerplate, letting developers focus on defining handlers for each primitive. Readers who complete both the original and this follow-up should come away with a server that implements Tools, Resources, and Prompts, which is a fuller expression of what the protocol is designed to support.

The broader context is that MCP adoption has grown quickly, with support appearing in various desktop assistants, editors, and agent frameworks, and a range of community and vendor-built servers for services such as file systems, databases, and popular developer tools. As the ecosystem matures, discussions around authentication, remote server security, and registry discovery continue to evolve alongside the specification. For developers, that trajectory suggests learning the complete primitive set is a reasonable investment rather than an optional extra. Tutorials like this one lower the barrier by grounding the specification in concrete implementation, and the emphasis on all three capabilities appears aimed at readers who intend to build production-grade servers rather than experiment with a single feature in isolation.