Skip to content

Blog

MCP tools, resources and prompts: differences and tests

Understand MCP tools, resources and prompts with methods, examples and a practical client check. Diagnose missing features without rebuilding your whole setup.

Published on · by tracevero · Reading time 4 minutes (696 words)

An MCP server can expose executable tools, readable resources and prepared conversation templates. These are called tools, resources and prompts. They serve different purposes and may appear in different parts of a client. Inspecting the tool menu alone can therefore miss part of the available functionality. Use this guide to classify the feature you expect and test it directly before changing an otherwise working configuration.

Which feature does your task need?

Begin with the action you want: run a search, read a supplied document or select a reusable template. Protocol revision 2025-11-25 assigns different methods to those operations. The table maps each feature to its discovery and retrieval methods. Its examples describe possible uses, not a promise that every server provides them. Confirm the actual inventory of the version you are connecting to.

Three kinds of server features
FeatureExampleMethods
ToolRun a searchtools/list, tools/call
ResourceRead a supplied documentresources/list, resources/read
PromptRetrieve a template with argumentsprompts/list, prompts/get

A resource has a URI, which need not be a public web address: servers can use a custom URI scheme. Parameterized resources are described through resources/templates/list. A prompt returns a template containing messages; retrieving it does not mean that tools mentioned in those messages have already run. A tool has a name and an input schema describing the arguments it accepts.

Separate server capabilities from the client interface

Capabilities are negotiated during connection setup. A server does not have to implement all three features. A client may also support features without displaying them in the same menu. Record the server version, client version and expected feature. An empty tool menu alone does not demonstrate that the connection has completely failed. First establish whether you are looking for a tool, a resource or a prompt.

A practical verification path 1. Expectation Identify the feature 2. Inventory Read the matching list 3. Result Check one operation
Suggested checks for your setup; no provider test is claimed.

Use the Inspector guide for a separate check, then compare the server inventory with your client. The client overview helps you choose the correct setup. Successfully listing features establishes that the list was retrieved. Test the operation and its output separately before treating the connection as ready for your actual task.

Keep a small verification record

  1. Choose an uncritical test document, query or template. Write down the expected result before starting.

  2. Read the matching inventory. Include subsequent pages if the response contains a nextCursor.

  3. Retrieve exactly the selected feature: call a tool with its required arguments, read a resource URI or retrieve a prompt with its parameters.

  4. Compare the result with your expectation. Record method, name, time and outcome without credentials.

For your own test, create a document containing the line “October test record”. If the server exposes that document as a resource, read its URI and find the line in the response. If it instead offers a file-reading tool, test that tool. The same content may be accessible through different features; use the interface documented by your chosen server. This is a suggested test, not a claim that a particular provider has been tested.

Distinguish missing features from failed operations

An unknown method, an empty list and a failed tool call are different findings. For tools, also inspect the result’s isError flag. The missing tools guide covers inventory problems. If the connection never initializes, start with the troubleshooting navigator. Change one setting at a time and repeat the same operation so you can identify which correction actually changed the result.

Does every MCP server implement all three features?
No. Check the capabilities and documentation for the specific version.
Is a resource always a file?
No. Resources address different kinds of content with a URI. The scheme does not have to be HTTP.
Does prompts/get automatically run tools?
The request retrieves the template. Further processing is handled by the client.
Does tools/list prove access to my data?
No. Also run a bounded operation and verify its output.

Official documentation checked on 1 October 2026. Examples and checklists are editorial suggestions.

  1. MCP tools
    Show retrieval commandcurl -s https://modelcontextprotocol.io/specification/2025-11-25/server/tools
  2. MCP resources
    Show retrieval commandcurl -s https://modelcontextprotocol.io/specification/2025-11-25/server/resources
  3. MCP prompts
    Show retrieval commandcurl -s https://modelcontextprotocol.io/specification/2025-11-25/server/prompts
  4. MCP architecture
    Show retrieval commandcurl -s https://modelcontextprotocol.io/specification/2025-11-25/architecture

Put it into practice

All posts

tracevero · https://tracevero.com/blog/mcp-tools-resources-prompts-guide