MCP Prompts

Introduction

Prompts are the third core primitive in MCP, alongside tools and resources. While tools let LLMs perform actions and resources provide data, prompts offer reusable templates that structure LLM interactions. Prompts are user-controlled — they are selected by the user or client, not invoked autonomously by the LLM. This distinction is fundamental to understanding their role in the MCP architecture.

Key Concepts

An MCP prompt is a template exposed by a server that generates structured messages for LLM interactions. Each prompt has a name, an optional title (a human-readable display name), an optional description, and can accept arguments to produce dynamic content tailored to specific use cases.

The three MCP primitives serve distinct purposes:

• Tools: Executable functions the LLM can invoke (actions)
• Resources: Read-only data the LLM can access (context)
• Prompts: Reusable templates for structuring LLM interactions (templates)

Prompts are discovered via prompts/list, which returns an array of available prompt definitions.

Here is an example of a prompts/list response:

json
{
  "prompts": [
    {
      "name": "code_review",
      "title": "Code Review",
      "description": "Review code for bugs, style, and best practices",
      "arguments": [
        {
          "name": "language",
          "description": "The programming language",
          "required": true
        },
        {
          "name": "code",
          "description": "The code to review",
          "required": true
        }
      ]
    }
  ]
}

This tells the client what prompts are available and what arguments they accept.

To retrieve a prompt with its arguments filled in, the client sends a prompts/get request:

json
{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "prompts/get",
  "params": {
    "name": "code_review",
    "arguments": {
      "language": "python",
      "code": "def add(a, b): return a + b"
    }
  }
}

The server responds with a fully rendered prompt containing messages ready to send to the LLM.

Real World Context

A development tooling server might expose prompts like "code_review", "explain_error", and "write_tests". When a developer selects "code_review" from a menu, the client fills in the arguments (language and code) and retrieves the structured prompt. This is more reliable than asking the user to write their own review instructions every time — the template ensures consistency and quality.

Deep Dive

Prompts differ from tools in a critical way: tools are invoked by the LLM as part of its reasoning, while prompts are selected by the user or client to start or guide an interaction. A prompt is like a recipe card — the user picks it, fills in the ingredients (arguments), and hands it to the LLM. A tool is like a kitchen appliance — the LLM decides when to use it during cooking.

Arguments make prompts dynamic. A summarize prompt might accept a length argument (short, medium, long) and a topic argument. The server uses these to generate tailored instructions that guide the LLM's behavior. Required arguments must be provided; optional arguments have sensible defaults.

Here is a prompt response with dynamic content:

json
{
  "description": "Code review prompt for Python",
  "messages": [
    {
      "role": "user",
      "content": {
        "type": "text",
        "text": "Please review this Python code for bugs, style issues, and best practices:\n\ndef add(a, b): return a + b"
      }
    }
  ]
}

The response contains a messages array that the client can send directly to the LLM.

Common Pitfalls

• Confusing prompts with tools: Prompts are templates selected by users. Tools are functions invoked by the LLM. They serve different purposes.
• Ignoring argument validation: Required arguments should be validated before sending prompts/get. Missing arguments lead to incomplete or incorrect templates.
• Treating prompts as static strings: Prompts are dynamic — they use arguments to generate context-specific messages. Take advantage of this flexibility.

Best Practices

• Expose prompts for recurring workflows where consistency matters (code review, data analysis, error investigation).
• Use clear argument names and descriptions so the client can build intuitive UIs for users.
• Keep prompt templates focused on a single task to avoid confusion.
• Document what each prompt produces so users know what to expect.

Summary

MCP prompts are reusable, server-defined templates that structure LLM interactions. They are discovered via prompts/list, retrieved via prompts/get with arguments, and produce ready-to-use message arrays. Unlike tools, prompts are user-controlled — they are selected by the user, not invoked by the LLM.

{
  "prompts": [
    {
      "name": "code_review",
      "title": "Code Review",
      "description": "Review code for bugs, style, and best practices",
      "arguments": [
        { "name": "language", "required": true },
        { "name": "code", "required": true }
      ]
    }
  ]
}

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "prompts/get",
  "params": {
    "name": "code_review",
    "arguments": { "language": "python", "code": "def add(a, b): return a + b" }
  }
}