Create a Custom MCP Client To Learn and Manage Your AWS Services and Resources

In the last few posts, we've learned how to create a custom MCP server that has deep knowledge of our Amazon Interactive Video Service (Amazon IVS) resources. The server exposes many tools to retrieve information about our low-latency channels, real-time streams and chat rooms. It also has access to query a custom RAG knowledge base that contains Amazon IVS documentation, so it knows how to answer specific code-related questions regarding Amazon IVS and can even fetch URLs directly from the web. A very powerful server indeed! But we've not yet created a way to interact with this server, so in this post we'll create a custom MCP client that can use the tools exposed by our MCP server. The client will invoke Claude 3.7 via the Amazon Bedrock Converse API. When we invoke Claude via Bedrock, we'll tell it the tools that it can use to answer our prompts and it'll automatically decide the best tool (if any) to use to respond. As a reminder, here is an overview of the entire architecture that we've been discussing throughout this series. At the very least, our client will accept user input via stdio, and pass that input as a prompt to Claude via Amazon Bedrock. What happens next depends largely on what Claude responds. If it can answer the prompt without using a tool, it will. Or, it'll decide that it needs to invoke a tool and will let us know which tool it wants to use and what parameters it wants to send to that tool. Our client code is responsible for handling this part of the interaction. If Bedrock returns a stopReason of tool_use, our client calls the tool on our MCP server and adds the tool response to our message context and sends that back to Bedrock. Bedrock might be happy with this, or it might decide to use another tool. The client must manage this back and forth until a stopReason of end_turn is received. As you can imagine, it's a good idea to limit this back-and-forth interaction to a maximum amount of turns to avoid an infinite loop! Creating the MCP Client We'll again use the @modelcontextprotocol/sdk library for our MCP client. To start, create a new project and install the SDK.

Apr 9, 2025 - 15:22

Create a Custom MCP Client To Learn and Manage Your AWS Services and Resources

In the last few posts, we've learned how to create a custom MCP server that has deep knowledge of our Amazon Interactive Video Service (Amazon IVS) resources. The server exposes many tools to retrieve information about our low-latency channels, real-time streams and chat rooms. It also has access to query a custom RAG knowledge base that contains Amazon IVS documentation, so it knows how to answer specific code-related questions regarding Amazon IVS and can even fetch URLs directly from the web. A very powerful server indeed! But we've not yet created a way to interact with this server, so in this post we'll create a custom MCP client that can use the tools exposed by our MCP server. The client will invoke Claude 3.7 via the Amazon Bedrock Converse API. When we invoke Claude via Bedrock, we'll tell it the tools that it can use to answer our prompts and it'll automatically decide the best tool (if any) to use to respond.

As a reminder, here is an overview of the entire architecture that we've been discussing throughout this series.

At the very least, our client will accept user input via stdio, and pass that input as a prompt to Claude via Amazon Bedrock. What happens next depends largely on what Claude responds. If it can answer the prompt without using a tool, it will. Or, it'll decide that it needs to invoke a tool and will let us know which tool it wants to use and what parameters it wants to send to that tool. Our client code is responsible for handling this part of the interaction. If Bedrock returns a stopReason of tool_use, our client calls the tool on our MCP server and adds the tool response to our message context and sends that back to Bedrock. Bedrock might be happy with this, or it might decide to use another tool. The client must manage this back and forth until a stopReason of end_turn is received. As you can imagine, it's a good idea to limit this back-and-forth interaction to a maximum amount of turns to avoid an infinite loop!

Creating the MCP Client

We'll again use the @modelcontextprotocol/sdk library for our MCP client. To start, create a new project and install the SDK.