Beyond Tools in MCP: Designing with Resources, Prompts, and Sampling

Prompts: let routines accumulate on the server

A prompt registers a reusable message template on the server side. It takes arguments and returns a pre-assembled message sequence. In many clients it shows up like a slash command that the user picks and launches.

That's what the earlier review_metadata tool actually wanted to be. Moving it from tool to prompt turns the review routine into a server asset, so the caller no longer rewrites the prompt.

server.prompt(
  "review_for_store",
  { id: z.string(), locale: z.string().default("en") },
  async ({ id, locale }) => {
    const meta = await db.meta(id);
    return {
      messages: [
        {
          role: "user",
          content: {
            type: "text",
            text: [
              `Review the following wallpaper metadata for the ${locale} App Store / Google Play.`,
              "Lenses: title appeal, description length limits, banned phrasing, category fit.",
              "Give the corrected copy itself rather than a bulleted list of suggestions.",
              "",
              JSON.stringify(meta, null, 2),
            ].join("\n"),
          },
        },
      ],
    };
  }
);

The payoff of keeping this as a prompt is that writing the routine carefully once lets all six apps run reviews at the same quality. In my case I concentrated the checks for phrasing that tends to get rejected in store review (overblown claims like "best" or "No.1") into this prompt. I used to hand-write the prompt through a tool every time, so the lenses drifted from app to app; fixing them in a prompt erased that drift.

The difference between prompt and tool in one line: a prompt is "a user-initiated standing request," a tool is "an operation the model calls when needed." Reviews, summaries, naming-convention checks — work that a human launches by saying "do this" — suits a prompt.

Sampling: borrow the client's inference from the server

Sampling is the most misunderstood of the three. It's the mechanism by which the server asks the client's LLM to run inference. Rather than the server holding its own API key and calling Claude, it sends a sampling/createMessage request to the client; the client (with the user's approval) generates with the model at hand and returns the result to the server.

This shines when you want to slip a bit of light natural-language generation into the middle of server processing. In my case, when a new wallpaper is ingested, I wanted a caption draft built from the filename and color information. The value of sampling is achieving this without the server becoming the billing party.

server.tool(
  "ingest_wallpaper",
  { id: z.string(), filename: z.string() },
  async ({ id, filename }) => {
    const palette = await analyzePalette(id); // existing color analysis
 
    // Ask the client's LLM to draft a caption
    const result = await server.server.createMessage({
      messages: [{
        role: "user",
        content: {
          type: "text",
          text: `From the filename "${filename}" and dominant colors ${palette.join(", ")}, ` +
                `give three wallpaper-app captions, each under 8 words.`,
        },
      }],
      maxTokens: 200,
    });
 
    const caption = result.content.type === "text" ? result.content.text : "";
    await db.saveCaptionDraft(id, caption);
    return { content: [{ type: "text", text: `Saved caption drafts:\n${caption}` }] };
  }
);

The key point is that whether server.server.createMessage() succeeds depends entirely on whether the connected client supports sampling. Send it to a client that doesn't, and it errors. The next section handles that real-world constraint.

How to choose among the three

Here is the decision framework. The order I ask myself is fixed.

First, is it state-changing or read-only? If read-only, consider a resource; if it changes state, consider a tool. Second, is it a user-initiated routine? Work launched with "do this," like review or summary, becomes a prompt. Third, do I want to slip natural-language generation into the middle of server processing? If so, consider sampling — but always verify client support.

Spelled out as concrete mappings:

1. Fetching the wallpaper list and individual metadata → resource (no side effects, reference material)
2. Re-running classification, regenerating thumbnails, updating the publish flag → tool (state-changing)
3. Store-facing metadata review and naming-convention checks → prompt (human-initiated routine)
4. Caption drafting at ingest time → sampling used inside a tool

Applying this, the fourteen tools came down to five: reclassify, regenerate thumbnail, update publish flag, ingest, and bulk-replace tags. The eight read-only ones moved to resources, the review ones moved to prompts, and the server's responsibilities split cleanly. Claude's tool mix-ups have been essentially zero since this refactor.

How I actually rebuilt the wallpaper asset server

Doing the whole migration at once breaks things, so I went in stages. I first added the resources and ran them in parallel with the read-only tools. Only after confirming in conversation that Claude reads the resources correctly did I delete the tool versions. Keeping that parallel window helped me catch the "Claude stopped referencing it once it became a resource" pitfall early.

Next came the move to prompts. When rewriting the review tools as prompts, I designed the argument defaults carefully. Defaulting locale to en means I only pass ja for the Japanese store, which shaves friction off daily work. In indie development, trimming small frictions like this compounds.

I advanced the sampling integration most cautiously. Caption generation is strictly a "draft," and I keep final decisions in my own hands. I didn't adopt a design that fully automates rewriting store copy tied directly to AdMob revenue — the quality variance scared me. Drafts are saved, and I review and adopt them. That's a judgment scaled to one developer's risk tolerance, and there isn't a single right answer.

Heavy work like color analysis and thumbnail generation stayed in the server's native implementation, as before. I limit sampling to light natural-language generation and never throw image processing at an LLM. When adding primitives becomes the goal in itself, complexity balloons, so I keep asking "does this step truly need inference?"

The real constraint of client support

A beautiful design won't run if the client you connect doesn't support it. This surfaces especially with sampling. Tools and resources are supported by nearly every client, but prompt and sampling support varies. Depending on sampling in production outright risks the entire ingest feature dropping the moment you switch clients.

What I use is a fallback that degrades quietly when sampling isn't available. I wrap the createMessage call in try/catch; on failure it skips only caption generation and still completes the ingest.

async function tryGenerateCaption(filename: string, palette: string[]): Promise<string | null> {
  try {
    const result = await server.server.createMessage({
      messages: [{
        role: "user",
        content: { type: "text", text: `One caption under 8 words from "${filename}" and colors ${palette.join(", ")}.` },
      }],
      maxTokens: 100,
    });
    return result.content.type === "text" ? result.content.text : null;
  } catch {
    // Client without sampling support, or the user declined
    return null; // never stop the ingest itself
  }
}

Since adopting this, I've been able to connect the same server from Claude Desktop and Claude Code without thinking about the support gap. The "convenience kicks in where it's available and nothing breaks where it isn't" mindset pays off most for people who move between several environments in indie work.

One more practical note: sampling is designed to go through user approval. Some clients pop a confirmation dialog every time, so it's a poor fit for batch workflows that ingest many wallpapers at once. I review ingests one image at a time, so it never bit me, but if you're after unattended bulk processing, there are cases where an independent server-side API call beats sampling. Here again, the operational call — how far to widen the automation — comes first.

If you want a next step, write out your own MCP server's tool list and sort each entry into read / operation / routine / inference. Seeing how many reads are hiding among your tools makes the first refactor to run obvious. I hope this helps anyone whose tool list has grown past the point of being legible.