[FEATURE] Strands MCP client should support prompts/resources/sampling

[shamikatamazon]

Problem Statement

Currently the strands MCP client only supports tools, which is only a part of the MCP spec. The other functionality like prompts/resources and sampling should also be supported in the Strands MCP client

Proposed Solution

No response

Use Case

Allowing the Strands MCP client to support resources/prompts and sampling will allow Strands to leverage the entire power of MCP, not just the tools functionality

Alternatives Solutions

No response

Additional Context

No response

[dbschmigelski]

The current design has agents interacting with MCP servers through the AgentTool interface, where mcp tools are exposed via list_tools_sync and provided to the agent. The key architectural question this feature raises is how we should expose this functionality to the user and the Agent.

There seem to be two different use cases.

One is that an engineer will want the Agent to interact with prompts on its own. In this scenario, mapping prompts to AgentTools makes sense. For example, similar to our list_tools->call_tool approach, we would add a list_prompts which would return List[AgentTool] representing a list of tools capable of retrieving prompts. In this case "Tool" is overloaded as here a "tool" simply means "a thing the agent can use." The AgentTool, lets call it MCPPromptTool, would return the prompt to the agent.

The second use case, is wanting to retrieve prompts directly. For example,

with mcp_client:
    prompts = mcp_client.list_prompts()

this use case also seems reasonable. However, it may be awkward, in this case for list_prompts to return a ToolResult type.

The question we have to answer is this, should Prompts, Resources, etc be made available to the Agent/user via AgentTool, or should they be made first class citizens in the SDK through some other mechanism. More clearly, is GetPrompt a "tool" or is there something fundamental which necessitates a different approach.

[theagenticguy]

Based on my understanding, Prompts and Resources are primitives that are used more deterministically in code, rather than self-determined by an agent. E.g. you might start an MCP client, get a Prompt, format with your prompt inputs, then start the agent with the formatted string.

Resource is slightly similar, except it's nice to be able to update a Resource and list changes.

In any case, it seems like a two way door to implement at least these two primitives in the tools/mcp MCPClient and see what people do with them! Perhaps then, they should be 1st class returned types rather than AgentTool

[dbschmigelski]

I agree @theagenticguy, I do not want to be too prescriptive, but definitely want to leave the door open for the agents to leverage the MCP server on its own.

Based on the MCP documentation resources do seem like something an agent may want to retrieve at runtime though

Resources represent any kind of data that an MCP server wants to make available to clients. This can include:

File contents
Database records
API responses
Live system data
Screenshots and images
Log files
And more

I agree, though I believe most implementations have been shoving many of these would-be resources into tools. So I'm curious if customer habits have diverged from documented intent. Curious what your experience has been with customers regarding that! I think as next steps we are going to workshop a document which will help us explore/deifne the customer requirements for MCP moving forward

Edit: It does look like their is guidance from MCP defining application-controlled, user-controlled and model-controlled primitives. We will adhere to these as we progress

Resources are designed to be application-controlled, meaning that the client application can decide how and when they should be used. Different MCP clients may handle resources differently. For example:

Claude Desktop currently requires users to explicitly select resources before they can be used
Other clients might automatically select resources based on heuristics
Some implementations may even allow the AI model itself to determine which resources to use
Server authors should be prepared to handle any of these interaction patterns when implementing resource support. In order to expose data to models automatically, server authors should use a model-controlled primitive such as [Tools](https://modelcontextprotocol.io/docs/concepts/tools).