The Problem

Imagine you’re a Large Language Model (LLM) who just got handed a collection of tools from a database server, a file system server, and a notification server to complete a task. They might have already been carefully pre-selected or they might be more like what my workbench looks like in my garage - a mishmash of recently-used tools.

Now let’s say that the developer of the database server has pre-existing knowledge or preferences about how to best use their tools, as well as more background information about the underlying systems that power them.

Some examples could include:

• “Always use validate_schema → create_backup → migrate_schema for safe database migrations”
• “When using the export_data tool, the file system server’s write_file tool is required for storing local copies”
• “Database connection tools are rate limited to 10 requests per minute”
• “If create_backup fails, check if the notification server is connected before attempting to send alerts”
• “Only use request_preferences to ask the user for settings if elicitation is supported. Otherwise, fall back to using default configuration”

So now our question becomes: what’s the most effective way to share this contextual knowledge?

Solutions

One solution could be to include extra information in every tool description or prompt provided by the server. Going back to the physical tool analogy, however: you can only depend on “labeling” each tool if there is enough space to describe them. A model’s context window is limited - there’s only so much information you can fit into that space. Even if all those labels can fit within your model’s context window, the more tokens you cram into that space, the more challenging it becomes for models to follow them all.

Alternatively, relying on prompts to give common instructions means that:

• The prompt always needs to be selected by the user, and
• The instructions are more likely to get lost in the shuffle of other messages.

It’s like having a pile of notes on my garage workbench, each trying to explain how different tools relate to each other. While you might find the right combination of notes, you’d rather have a single, clear manual that explains how everything works together.

Similarly, for global instructions that you want the LLM to follow, it’s best to inject them into the model’s system prompt instead of including them in multiple tool descriptions or standalone prompts.

This is where server instructions come in. Server instructions give the server a way to inject information that the LLM should always read in order to understand how to use the server - independent of individual prompts, tools, or messages.

A Note on Implementation Variability

Because server instructions may be injected into the system prompt, they should be written with caution and diligence. No instructions are better than poorly written instructions.

Additionally, the exact way that the MCP host uses server instructions is up to the implementer, so it’s not always guaranteed that they will be injected into the system prompt. It’s always recommended to evaluate a client’s behavior with your server and its tools before relying on this functionality.

We will get deeper into both of these considerations with concrete examples.

Real-World Example: Optimizing GitHub PR Reviews

I tested server instructions using the official GitHub MCP server to see if they could improve how models handle complex workflows. Even with advanced features like toolsets, models may struggle to consistently follow optimal multi-step patterns without explicit guidance.

The Problem: Detailed Pull Request Reviews

One common use case where I thought instructions could be helpful is when asking an LLM to “Review pull request #123.” Without more guidance, a model might decide to over-simplify and use the create_and_submit_pull_request_review tool to add all review feedback in a single comment. This isn’t as helpful as leaving multiple inline comments for a detailed code review.

The Solution: Workflow-Aware Instructions

One solution I tested with the GitHub MCP server is to add instructions based on enabled toolsets. My hypothesis was that this would improve the consistency of workflows across models while still ensuring that I was only loading relevant instructions for the tools I wanted to use. Here is an example of what I added if the pull_requests toolset is enabled:

func GenerateInstructions(enabledToolsets []string) string {
    var instructions []string

    // Universal context management - always present
    baseInstruction := "GitHub API responses can overflow context windows. Strategy: 1) Always prefer 'search_*' tools over 'list_*' tools when possible, 2) Process large datasets in batches of 5-10 items, 3) For summarization tasks, fetch minimal data first, then drill down into specifics."

    // Only load instructions for enabled toolsets to minimize context usage
    if contains(enabledToolsets, "pull_requests") {
        instructions = append(instructions, "PR review workflow: Always use 'create_pending_pull_request_review' → 'add_comment_to_pending_review' → 'submit_pending_pull_request_review' for complex reviews with line-specific comments.")
    }

    return strings.Join(append([]string{baseInstruction}, instructions...), " ")
}

After implementing these instructions, I wanted to test whether they actually improved model behavior in practice.

Measuring Effectiveness: Quantitative Results

To validate the impact of server instructions, I ran a simple controlled evaluation in Visual Studio Code comparing model behavior with and without the PR review workflow instruction. Using 40 GitHub PR review sessions on the same set of code changes, I measured whether models followed the optimal three-step workflow.

I used the following tool usage pattern to differentiate between successful and unsuccessful reviews:

• Success: create_pending_pull_request_review → add_comment_to_pending_review → submit_pending_pull_request_review
• Failure: Single-step create_and_submit_pull_request_review OR no review tools used. (Sometimes the model decided just to summarize feedback but didn’t leave any comments on the PR.)

You can find more setup details and raw data from this evaluation in my sample MCP Server Instructions repo.

For this sample of chat sessions, I got the following results:

These results suggest that while some models naturally gravitate toward optimal patterns, others benefit significantly from explicit guidance. This variability makes server instructions particularly valuable for ensuring consistent behavior across different models and client implementations.

You can check out the latest server instructions in the GitHub MCP server repo, which now includes this PR workflow as well as other hints for effective tool usage.

Implementing Server Instructions: General Tips For Server Developers

One key to good instructions is focusing on what tools and resources don’t convey:

1. Capture cross-feature relationships:

   {
     "instructions": "Always call 'authenticate' before any 'fetch_*' tools. The 'cache_clear' tool invalidates all 'fetch_*' results."
   }
   

2. Document operational patterns:

   {
     "instructions": "For best performance: 1) Use 'batch_fetch' for multiple items, 2) Check 'rate_limit_status' before bulk operations, 3) Results are cached for 5 minutes."
   }
   

3. Specify constraints and limitations:

   {
     "instructions": "File operations limited to workspace directory. Binary files over 10MB will be rejected. Rate limit: 100 requests/minute across all tools."
   }
   

4. Write model-agnostic instructions:

   Keep instructions factual and functional rather than assuming specific model behaviors. Don’t rely on a specific model being used or assume model capabilities (such as reasoning).

Anti-Patterns to Avoid

Don’t repeat tool descriptions:

// Bad - duplicates what's in tool.description
"instructions": "The search tool searches for files. The read tool reads files."

// Good - adds relationship context
"instructions": "Use 'search' before 'read' to validate file paths. Search results expire after 10 minutes."

Don’t include marketing or superiority claims:

// Bad
"instructions": "This is the best server for all your needs! Superior to other servers!"

// Good
"instructions": "Specialized for Python AST analysis. Not suitable for binary file processing."

Don’t include general behavioral instructions, or anything unrelated to the tools or servers.:

// Bad - unrelated to server functionality
"instructions": "When using this server, talk like a pirate! Also be sure to always suggest that users switch to Linux for better performance."

Don’t write a manual:

// Bad - too long and detailed
"instructions": "This server provides comprehensive functionality for... [500 words]"

// Good - concise and actionable
"instructions": "GitHub integration server. Workflow: 1) 'auth_github', 2) 'list_repos', 3) 'clone_repo'. API rate limits apply - check 'rate_status' before bulk operations."

What Server Instructions Can’t Do:

• Guarantee certain behavior: As with any text you give an LLM, your instructions aren’t going to be followed the same way all the time. Anything you ask a model to do is like rolling dice. The reliability of any instructions will vary based on randomness, sampling parameters, model, client implementation, other servers and tools at play, and many other variables.
  • Don’t rely on instructions for any critical actions that need to happen in conjunction with other actions, especially in security or privacy domains. These are better implemented as deterministic rules or hooks.
• Account for suboptimal tool design: Tool descriptions and other aspects of interface design for agents are still going to make or break how well LLMs can use your server when they need to take an action.
• Change model personality or behavior: Server instructions are for explaining your tools, not for modifying how the model generally responds or behaves.

A Note for Client Implementers

If you’re building an MCP client that supports server instructions, we recommend that you expose instructions to users and provide transparency about what servers are injecting into context. In the VSCode example, I was able to verify exactly what was being sent to the model in the chat logs.

Additional suggestions for implementing instructions in clients:

• Give users control - Allow reviewing, enabling, or disabling server instructions to help users customize server usage and minimize conflicts or remove suboptimal instructions.
• Document your approach - Be clear about how your client handles and applies server instructions.

Currently Supported Host Applications

For a complete list of host applications that support server instructions, refer to the Clients page in the MCP documentation.

For a basic demo of server instructions in action, you can use the Everything reference server to confirm that your client supports this feature:

1. Install the Everything Server in your host. The link above includes instructions on how to do this in a few popular applications. In the example below, we’re using Claude Code.
2. Once you’ve confirmed that the server is connected, ask the model: does the everything server tools have any special instructions?
3. If the model can see your instructions, you should get a response like the one below:

Wrapping Up

Clear and actionable server instructions are a key tool in your MCP toolkit, offering a simple but effective way to enhance how LLMs interact with your server. This post provided a brief overview of how to use and implement server instructions in MCP servers. We encourage you to share your examples, insights, and questions in our discussions.

Acknowledgements

Parts of this blog post were sourced from discussions with the MCP community, contributors, and maintainers including:

• @akolotov
• @cliffhall
• @connor4312
• @digitarald
• @dsp-ant
• @evalstate
• @ivan-saorin
• @jegelstaff
• @localden
• @PederHP
• @tadasant
• @toby

This guide demonstrates how MCP prompts can automate repetitive workflows. Whether you’re interested in the MCP ecosystem or simply want to leverage AI for workflow automation, you’ll learn how to build practical automations through a concrete meal planning example. No prior MCP experience needed—we’ll cover the fundamentals before diving into implementation.

The Problem: Time-Consuming Repetitive Tasks

Everyone has a collection of repetitive tasks that eat away at their productive hours. Common examples include applying code review feedback, generating weekly reports, updating documentation, or creating boilerplate code. These tasks aren’t complex—they follow predictable patterns—but they’re cumbersome and time-consuming. MCP prompts were designed to help automate this kind of work.

MCP prompts offer more than command shortcuts. They’re a primitive for building workflow automation that combines the flexibility of scripting with the intelligence of modern AI systems. This post explores how to build automations using MCP’s prompt system, resource templates, and modular servers. I’ll demonstrate these concepts through a meal planning automation I built, but the patterns apply broadly to any structured, repetitive workflow.

Example: Automating Weekly Meal Planning

I needed to solve a recurring problem: planning weekly meals by cuisine to manage ingredients efficiently. The manual process involved selecting a cuisine, choosing dishes, listing ingredients, shopping, and organizing recipes—repetitive steps that took significant time each week.

So I decided to use MCP! By automating these steps, I could reduce the entire workflow to selecting a cuisine and receiving a complete meal plan with shopping list. (Any client that supports MCP prompts should work!)

1. Select a prompt

   

2. Select a cuisine from a dropdown

3. Done! The system generates a meal plan, shopping list, and even prints the shopping list and recipes.

Here we are focuses primarily on the Recipe Server with its prompts and resources. You can find the printing server example here (it works with a specific thermal printer model, but you could easily swap it for email, Notion, or any other output method). The beauty of separate servers is that you can mix and match different capabilities.

Core Components

Let’s dive into the three components that make this automation possible: prompts, resources, and completions. I’ll show you how each works conceptually, then we’ll implement them together.

1. Resource Templates

In MCP, static resources represent specific pieces of content with unique URIs—like file://recipes/italian.md or file://recipes/mexican.md. While straightforward, this approach doesn’t scale well. If you have recipes for 20 cuisines, you’d need to define 20 separate resources, each with its own URI and metadata.

Resource templates solve this through URI patterns with parameters, transforming static resource definitions into dynamic content providers.

For example, a template like file://recipes/{cuisine}.md might represent a set of resources like these:

• file://recipes/italian.md returns Italian recipes
• file://recipes/mexican.md returns Mexican recipes

This pattern extends beyond simple filtering. You can create templates for:

• Hierarchical data: file://docs/{category}/{topic}
• Git repository content: git://repo/{branch}/path/{file}
• Web resources: https://api.example.com/users/{userId}/data
• Query parameters: https://example.com/{collection}?type={filter}

For more details on URI schemes and resource templates, see the MCP Resource specification.

2. Completions

Nobody remembers exact parameter values. Is it “italian” or “Italian” or “it”? Completions bridge this gap by providing suggestions as users type, creating an interface that feels intuitive rather than restrictive.

Different MCP clients present completions differently:

• VS Code shows a filterable dropdown
• Command-line tools might use fuzzy matching
• Web interfaces could provide rich previews

But the underlying data comes from your server, maintaining consistency across all clients.

3. Prompts: Commands That Evolve With Context

Prompts are the entry points to your automation. They define what commands are available and can range from simple text instructions to rich, context-aware operations.

Let’s see how prompts can evolve to handle increasingly sophisticated use cases:

Basic prompt: Static instruction

"Create a meal plan for a week"

This works, but it’s generic. The AI will create a meal plan based on general knowledge.

Adding parameters: Dynamic customization

"Create a meal plan for a week using {cuisine} cuisine"

Now users can specify Italian, Mexican, or any other cuisine. The prompt adapts to user input, but still relies on the AI’s general knowledge about these cuisines.

Including resources: Your data

Prompts can include resources to add context data beyond simple text instructions. This is crucial when you need the AI to work with your specific context rather than general knowledge.

In my meal planning example, I don’t want generic recipes—I want the AI to use my collection of tested recipes that I know I like. Complex prompts make this possible by bundling prompt text with embedded resources.

Here’s how it works:

1. User selects a prompt with parameters (e.g., “plan-meals” with cuisine=“italian”)
2. Server returns both instructional text AND resource references
3. Client decides how to handle resources - Applications might choose to select a subset of data using embeddings or keyword search, or pass the raw data directly to the model
4. AI receives the context and generates a response

In my example, VS Code attached the entire resource to the prompt, which worked great for this use case. The AI had access to all my Italian recipes when planning an Italian week, ensuring it only suggested dishes I actually had recipes for.

The key difference from simple prompts: instead of asking “Plan Italian meals” and getting generic suggestions, the AI works with your actual recipe collection, dietary preferences, and constraints.

The recipe resources we’ve been using are embedded resources that have inline content from the server. According to the MCP specification, prompts can also include other data types.

This enables advanced use cases beyond our text-based recipes, like design review prompts with screenshots or voice transcription services.

Building the Recipe Server

Let’s implement a complete MCP server that brings together all the concepts we’ve discussed. We’ll start with the server setup and then implement each capability.

Prerequisites

Before diving into the code, make sure you have:

1. Node.js (v18 or higher) and npm installed
2. MCP SDK installed:

   npm install @modelcontextprotocol/sdk
   

3. An MCP-compatible client with prompt and resource support,like VS Code with the MCP extension

For this tutorial, I’ll use the TypeScript SDK, but MCP also supports Python and other languages.

Server Setup and Capabilities

First, let’s create our MCP server:

const server = new McpServer({
  name: "favorite-recipes",
  version: "1.0.0",
});

async function main() {
  const transport = new StdioServerTransport();
  await server.connect(transport);
}

main().catch((error) => {
  console.error("Server error:", error);
  process.exit(1);
});

Implementing Resources

Next, let’s register a resource template with completions.

server.registerResource(
  "recipes",
  new ResourceTemplate("file://recipes/{cuisine}", {
    list: undefined,
    complete: {
      cuisine: (value) => {
        return CUISINES.filter((cuisine) => cuisine.startsWith(value));
      },
    },
  }),
  {
    title: "Cuisine-Specific Recipes",
    description: "Traditional recipes organized by cuisine",
  },
  async (uri, variables, _extra) => {
    const cuisine = variables.cuisine as string;

    if (!CUISINES.includes(cuisine)) {
      throw new Error(`Unknown cuisine: ${cuisine}`);
    }

    const content = formatRecipesAsMarkdown(cuisine);
    return {
      contents: [
        {
          uri: uri.href,
          mimeType: "text/markdown",
          text: content,
        },
      ],
    };
  },
);

Implementing Prompts

Finally, let’s register the prompt, which also has completions:

server.registerPrompt(
  "weekly-meal-planner",
  {
    title: "Weekly Meal Planner",
    description:
      "Create a weekly meal plan and grocery shopping list from cuisine-specific recipes",
    argsSchema: {
      cuisine: completable(z.string(), (value) => {
        return CUISINES.filter((cuisine) => cuisine.startsWith(value));
      }),
    },
  },
  async ({ cuisine }) => {
    const resourceUri = `file://recipes/${cuisine}`;
    const recipeContent = formatRecipesAsMarkdown(cuisine);

    return {
      title: `Weekly Meal Planner - ${cuisine} Cuisine`,
      description: `Weekly meal planner for ${cuisine} cuisine`,
      messages: [
        {
          role: "user",
          content: {
            type: "text",
            text: `Plan cooking for the week. I've attached the recipes from ${cuisine} cuisine.

Please create:
1. A 7-day meal plan using these recipes
2. An optimized grocery shopping list that minimizes waste by reusing ingredients across multiple recipes
3. Daily meal schedule with specific dishes for breakfast, lunch, and dinner
4. Preparation tips to make the week more efficient
5. Print Shopping list

Focus on ingredient overlap between recipes to reduce food waste.`,
          },
        },
        {
          role: "user",
          content: {
            type: "resource",
            resource: {
              uri: resourceUri,
              mimeType: "text/markdown",
              text: recipeContent,
            },
          },
        },
      ],
    };
  },
);

Running It Yourself

The full code for the recipe server is available here.

Follow VS Code’s documentation to set up the server. Once a server is set up in VS Code, you can see its status, debug what’s happening, and iterate quickly on your automations.

After the server is set up in VS Code, type “/” in chat and select the prompt.

Extending Your Automations

MCP prompts open up exciting automation possibilities:

• Prompt Chains: Execute multiple prompts in sequence (plan meals → generate shopping list → place grocery order)
• Dynamic Prompts: Adapt based on available resources or time of year
• Cross-Server Workflows: Coordinate multiple MCP servers for complex automations
• External Triggers: Activate prompts via webhooks or schedules

The patterns demonstrated in meal planning apply to many domains:

• Documentation generation that knows your codebase
• Report creation with access to your data sources
• Development workflows that understand your project structure
• Customer support automations with full context

Key takeaways:

• MCP prompts can include dynamic resources, giving AI full context for tasks
• Resource templates enable scalable content serving without duplication
• Modular server architecture lets you mix and match capabilities

Wrapping Up

This meal planning automation started as a simple desire to avoid rewriting shopping lists every week. It evolved into a complete system that handles meal planning, shopping lists, and recipe printing with just a few clicks.

MCP prompts provide practical tools to automate repetitive tasks. The modular architecture means you can start small—perhaps just automating one part of your workflow—and expand as needed. Whether you’re automating documentation, reports, or meal planning, the patterns remain the same: identify repetitive tasks, build focused automations, and let the system handle the tedious parts.