MCP Core Concepts

Prompts

Prompts are reusable templates for common LLM interactions that users can select. They provide a way to standardize and share common workflows. A common way clients expose prompts is through slash commands: a prompt template like "new ticket" might appear as a /new-ticket command that works in both Claude Desktop and your IDE.

Prompt Structure

type Prompt = {
  name: string;
  description?: string;
  arguments?: [
    {
      name: string;
      description?: string;
      required?: boolean;
    }
  ]
}

Key Characteristics

• Prompts are user-controlled. Unlike tools that the LLM can invoke autonomously, prompts require explicit user selection, ensuring users maintain control over their AI interactions.

• Can include embedded resource context and multi-step workflows. Prompts can automatically pull in relevant files, database records, or API responses, then guide the LLM through complex reasoning chains.

• Often surface as UI elements like slash commands or menu items. Clients typically expose prompts as "/debug-error", quick actions in command palettes, or contextual menu options for intuitive access.

• Support dynamic content generation based on arguments. Users can provide parameters like file paths, date ranges, or search queries that customize the prompt's behavior for each use.

Advanced patterns

• Multi-step workflows: Chain multiple interactions for complex tasks. For example, a debugging prompt might first analyze error logs, then examine relevant code, and finally suggest fixes with test cases.

• Resource embedding: Include dynamic resource content in prompts. A code review prompt could automatically fetch recent commits, pull request descriptions, and coding standards documentation.

• Parameterized templates: Accept user inputs to customize behavior. Templates can use variables like {{language}} or {{framework}} to generate context-specific guidance.

• Context-aware prompts: Adapt based on available server capabilities. Prompts can check which tools or resources are available and adjust their approach accordingly.

Best practices

• Use clear, action-oriented names (e.g., "analyze-code" not "code"). Names should immediately convey what the prompt does, making selection intuitive for users browsing available options.

• Provide detailed descriptions to guide user selection. Include what the prompt does, what arguments it expects, and what kind of output users can expect to receive.

• Validate all required arguments before generating prompt. Check that file paths exist, date formats are valid, and required parameters are provided to prevent confusing errors.

• Consider versioning for evolving prompt templates. As prompts improve, use versioning (e.g., "analyze-code-v2") to maintain backward compatibility while offering enhanced versions.

• Test prompts with various parameter combinations. Ensure prompts handle edge cases like empty results, invalid inputs, or missing resources gracefully.

• Document expected outcomes and limitations. Tell users what the prompt can and cannot do, helping set appropriate expectations and prevent frustration.