MCP Resources, Prompts or Tools: How to Serve Context

Choose by who requests the context

A team deployment guide can appear as a resource, a prompt, or a tool result. The bytes may be similar; the decision about when those bytes enter the conversation changes. The MCP specifications describe resources as application-driven, prompts as user-controlled, and tools as model-controlled, while leaving hosts flexibility in their interfaces.

For a deployment assistant, I would expose the runbook as an addressable object, offer a review prompt for interactive use, and provide search and read tools for task-driven recall. Those are three entry points into one content store. Maintaining separate copies would make a primitive comparison turn into a content-consistency problem.

Resources give context an address

The MCP resource specification defines URI-identified content, discovered through resources/list and fetched through resources/read. Text content carries a URI, MIME type and text. Resource templates describe parameterized addresses. This suits a skill file the caller already knows it needs, or a memory selected from a catalog.

For example, a custom server could return this complete resources/read response using the current draft result format. The URI and content are illustrative:

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "resultType": "complete",
    "contents": [{
      "uri": "context://workspace/skills/deploy/SKILL.md",
      "mimeType": "text/markdown",
      "text": "# Deployment review\nCheck the target environment before proposing changes."
    }]
  }
}

A resource address gives you a reference to test and cite; it does not establish that every host will attach the content automatically. Keep the catalog compact, then retrieve the chosen file. In your server design, resolve custom URIs against authorized context records rather than treating their paths as permission to read arbitrary server files.

Prompts package an intentional workflow

The MCP prompt specification provides prompts/list and prompts/get, optional arguments, and returned messages with user or assistant roles. Its intended interaction is explicit user selection. A deployment_review prompt accepting a service name can frame a review, ask for missing inputs, and include relevant reference material.

That makes prompts useful for choosing an activity: “review this deployment using our checklist.” A remembered fact such as “the billing service deploys to the EU region” serves a different purpose. I would retrieve that fact as context within the activity rather than create a prompt for every remembered decision.

Do not equate an MCP prompt with native skill installation. The protocol returns messages; verify separately whether the host registers a skill, loads supporting files, or merely inserts text into the conversation. If your requirement is a reusable skill catalog, test discovery and loading of the skill body independently from invocation of a workflow template. The distinction matters when a user switches between an interactive editor and a scheduled agent.

Tools let the agent ask for missing context

The MCP tool specification defines discovery through tools/list, invocation through tools/call, and JSON Schema inputs. Tools can return ordinary text as well as richer content. Here is an illustrative tool definition for reading the same stored context:

{
  "name": "read_context",
  "description": "Read a known context URI. Use search_context first when the URI is unknown.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "uri": { "type": "string" }
    },
    "required": ["uri"],
    "additionalProperties": false
  }
}

My recommended fallback is a small search-and-read pair, with search returning short matches and read returning the selected body. Include the canonical URI in each result so the resource and tool paths refer to the same record. This lets you compare delivery behavior without comparing different documents.

The tool specification also permits resource links in results. A link alone is a poor fallback if the failing client cannot fetch resources; return the needed excerpt as text through the supported path. Preserve the distinction between recorded facts and skill instructions in that text. For response sizing, see reducing tokens in agent tool responses.

Check the client surface, not just the MCP checkbox

Documentation checked for this comparison shows several supported paths. Claude Code documents resource references using @server:protocol://resource/path, automatic resource-listing and reading tools, and MCP prompts as commands. VS Code documents Add Context > MCP Resources, MCP: Browse Resources, and prompt invocation through /<server>.<prompt>. Cursor's current MCP documentation lists tools, prompts and resources as supported.

These interfaces differ, and a support table does not demonstrate the recall behavior your task requires. For a custom HTTP context server, Claude Code documents this connection syntax; replace the example endpoint with your server and complete its authentication:

claude mcp add --transport http context https://context.example.com/mcp

After connecting, check three separate outcomes: the capability is discoverable, its content reaches the conversation, and the agent uses it correctly. Repeat in the exact environment you deploy, including any headless run. A resource picker can pass an interactive test while leaving your unattended retrieval requirement untested. Record client version, execution mode and observed result alongside the chosen primitive.

Serving portable context with SPYN3

SPYN3 serves context through context_list, context_read and context_search tools that any MCP client can use. An admin enables Memory & skills per workspace; it is off by default. Memory and skills live under personal or workspace spyn3:// paths. Reading needs call:tools; writing needs the separate write:memory permission. This gives clients a tool-based context path through the workspace endpoint, https://api.spyn3.com/agent/mcp. Recalled memory is labelled as recorded data, not instructions.

Run one comparison before choosing the default

Use a fixture small enough to inspect: one deployment decision, one skill containing a checklist, and one review prompt. Give the decision a distinctive test value. Serve the same records through each interface you intend to support, then run the following checks:

1. Ask a question requiring the decision without naming its URI. Check whether the client finds it and whether the answer contains the test value.
2. Request the skill by name. Confirm that the body reaches the conversation and the resulting review follows its checklist.
3. Invoke the review prompt with a service argument. Inspect the inserted messages and confirm the argument is applied.
4. Repeat a read as a caller without access. Require denial through both resource and tool paths, including discovery results.

Choose the simplest interface that passes your required paths. Add prompts for deliberate workflows and resources for addressable browsing when those improve the tested experience. If several interfaces remain, keep one authorization decision and one stored body behind them. Continue with designing an MCP memory server to define those paths and scopes.