When should you use a prompt template instead of just hardcoding instructions in a system prompt?
Quick Answer
Use an MCP prompt when the interaction is something a user should be able to discover and deliberately invoke — a specific, repeatable workflow tied to the domain the server covers (code review, incident triage, PR summarization) — especially if it should work consistently across any MCP-compatible host, not just one app's hardcoded system prompt. Hardcoding instructions into a host's own system prompt makes sense for behavior that should always be active regardless of which server is connected, or general guidance that isn't a distinct, user-selectable action. The practical test: if you'd want it to show up as a slash command a user can pick from a menu, and you want that same curated interaction portable across different MCP hosts, it belongs in a prompt; if it's really about how the assistant should behave in general, it belongs in the host's own system prompt, not a server-defined MCP prompt.
Detailed Answer
It's tempting to bake every good instruction into a system prompt and skip the MCP prompt primitive entirely. That works until you need the same curated interaction to be portable, or explicitly user-triggered, rather than always-on.
Where each belongs
| Use an MCP prompt when... | Use the host's system prompt when... |
|---|---|
| It's a specific, occasional workflow, not always-relevant | It should shape the assistant's behavior for the whole session |
| A user should be able to explicitly pick it from a list/slash command | There's no natural "invocation moment" — it's ambient guidance |
| It should work the same way across any MCP-compatible host | It's specific to one particular application's UX/branding |
| The server author is the domain expert on how to phrase this request | The host author is setting overall assistant tone/persona |
A concrete example
A server for an incident-management tool might expose a triage-incident prompt. Given an incident ID, it returns a carefully worded message instructing the model to pull timeline data, identify the likely root cause category, and draft a first Slack update — codifying the on-call team's actual triage playbook. That's a strong prompt candidate. It's a specific, occasional action a user explicitly triggers, and it should behave identically whether the user is in Claude Desktop, an IDE, or any other MCP host connected to that server.
Compare that to "always respond concisely and never use bullet points unless asked." That's a standing behavioral preference, not a discrete workflow a user invokes. It belongs in the host's system prompt, or a per-app setting, not as a server-defined MCP prompt.
The underlying principle
Prompts exist to make a server author's domain expertise about how to ask well reusable and portable across hosts. System prompts exist to configure how the assistant behaves in general, within one specific application. Conflating the two either buries a genuinely reusable workflow inside one app's private configuration, or clutters a host's general behavior with narrow, occasional-use instructions that most sessions never need.