How to develop the MCP client, capable of talking to our application running on AgentCore Runtime

Building AI Agents with Spring AI and Amazon Bedrock AgentCore

Building AI Agents with Spring AI and Amazon Bedrock AgentCore – Part 1 Introduction to the series

Building AI Agents with Spring AI and Amazon Bedrock AgentCore – Part 2 Deploy Conference Search application on AgentCore Runtime

Building AI Agents with Spring AI and Amazon Bedrock AgentCore – Part 3 Develop local MCP client for Conference application

Introduction

In part 2, we explained how to deploy and run our conference search application on the Amazon Bedrock AgentCore Runtime as the MCP server. In this article, we’ll develop the (MCP-) client, capable of talking to our application running on AgentCore Runtime.

Develop local MCP client for Conference Application

You can find the source code of the MCP client in my spring-ai-1.1-conference-app-agent-local repository.

Let’s go step-by-step through it.

Dependencies and Configuration

Let’s go step-by-step through it.

First, in pom.xml, we include, among others, those dependencies:

spring-ai-bom – to include the general Spring AI functionality.
spring-boot-starter-web – as we develop the MCP client as a web application.
spring-ai-starter-model-bedrock-converse -as we use foundational models on Amazon Bedrock.
spring-ai-starter-mcp-client-webflux – to develop an asynchronous Spring AI MCP Client. We can use spring-ai-starter-mcp-client to develop a synchronous one.

The SpringAIConferenceLocalMCPClient class is the main entry point to our application.

Second, in application.properties, we define some properties. Those are Spring AI-related:

spring.ai.bedrock.aws.region=us-east-1
spring.ai.bedrock.aws.timeout=10m
spring.ai.bedrock.converse.chat.options.max-tokens=100
spring.ai.bedrock.converse.chat.options.model=amazon.nova-lite-v1:0
spring.ai.mcp.client.type=ASYNC

We define the region where we host our application, and the timeout when talking to the Amazon Bedrock models. Then we also set the default Amazon Bedrock model to use and a maximal number of tokens, and the MCP client type to ASYNC. We can also set SYNC instead, but we need to use another Spring AI MCP client dependency as described above.

We also include some application-related properties:

cognito.user.pool.name=UserPoolForAgentCoreMCP
cognito.user.pool.client.name=UserPoolClientWithUserAndPasswordForAgentCoreMCP
cognito.auth.token.resource.server.id=AgentCoreResourceServerId
amazon.bedrock.agentcore.runtime.id=spring_ai_conference_search_agentcore_runtime-6dnMIL9455

These are individual properties, whose values we need to set from the deployment of the Conference search MCP server. We described the configuration, creation process, and those properties of the MCP server in part 2.

Please ignore other properties like amazon.bedrock. agentcore.gateway.url as we will need them when we extend our application in the next articles.

Spring Rest Controller

The whole application logic is in the SpringAIAgentController class.

We inject the values of individual properties and build AWS service clients (STS and Cognito). This is how we create the ChatClient, which is the main interface of Spring AI to talk to the LLMs:

public SpringAIAgentController(ChatClient.Builder builder, ChatMemory chatMemory, @Value("${aws.region}") String awsRegion) {
   var options = ToolCallingChatOptions.builder()
	.model("us.anthropic.claude-sonnet-4-6")
	.maxTokens(2000)
    .build();

    this.chatClient = builder.defaultOptions(options).build();
}

We show here that we can optionally build ToolCallingChatOptions and override the default model name and the maximum number of tokens defined in application.properties. Then, we build the ChatClient, and can optionally set ToolCallingChatOptions.

Below is how the code for the method looks, which will receive the prompt from the user:

@GetMapping(value = "/conference", consumes = "text/plain")
public Flux<String> conferenceSearch(@RequestParam String prompt) {
  var token = getAuthTokenViaHttpClient();
  var client = McpClient.async(getMcpClientTransport(token)).build();
  client.initialize();
  var toolsResult = client.listTools(); 
  for (var tool : toolsResult.block().tools()) { 
	logger.info("tool found " + tool); 
  }
		 
  var asyncMcpToolCallbackProvider = AsyncMcpToolCallbackProvider.builder()
     .mcpClients(client)
     .build();


  return this.chatClient.prompt().user(prompt)	
 	      .tools(new DateTimeTools())
          .toolCallbacks(syncMcpToolCallbackProvider.getToolCallbacks())
          .stream()
          .content();
}

Let’s break this code down and explain it. First, we need to obtain the JWT token:

var token = getAuthTokenViaHttpClient();

This, in turn, uses a bunch of Amazon Cognito services to achieve this goal:

private String getAuthTokenViaHttpClient() {
  var userPool = getUserPool();
  var userPoolClient = getUserPoolClient(userPool);
  var userPoolClientType = describeUserPoolClient(userPoolClient);
  var userPoolId = userPool.id();
  userPoolId = userPoolId.replace("_", "").toLowerCase();
  var url = "https://" + userPoolId + ".auth." + Region.US_EAST_1.id() + ".amazoncognito.com/oauth2/token";

  var SCOPE_STRING = RESOURCE_SERVER_ID + "/*";
  var entity = "grant_type=client_credentials&" + "client_id=" + userPoolClientType.clientId() + "&"
    + "client_secret=" + userPoolClientType.clientSecret() + "&" + "scope=" + SCOPE_STRING;

  try (var httpClient = HttpClients.createDefault()) {
     var httpPost = ClassicRequestBuilder.post(url)
       .setHeader("Content-Type", "application/x-www-form-urlencoded")
       .setEntity(entity).build();
     return httpClient.execute(httpPost, new AuthTokenResponseHandler());		
}

Here, we use the configuration of the user (client ) names and the resource server ID from application.properties to obtain the user (client) pool. Then we construct the URL and the body (entity) of the HTTP request to obtain the authentication token. Then, we execute this request and obtain the token from the response:

private class AuthTokenResponseHandler implements HttpClientResponseHandler<String> {
@Override
  public String handleResponse(ClassicHttpResponse response) throws HttpException, IOException {
	var inputStream = response.getEntity().getContent();
    var responseString = new String(inputStream.readAllBytes(), StandardCharsets.UTF_8);
	var responseMap = objectMapper.readValue(responseString, new TypeReference<Map<String, Object>>() {});
	return (String) responseMap.get("access_token");
   }
}

After we have obtained the token, we’re ready to create the (asynchronous as configured) MCP client:

var client = McpClient.async(getMcpClientTransport(token)).build();

Let’s describe what happens when we invoke the getMcpClientTransport method:

private McpClientTransport getMcpClientTransport(String token) {		
  var MCP_SERVER_ENDPOINT= this.getMCPServerEndpoint();
  var headerValue = "Bearer " + token;
  var webClientBuilder = WebClient.builder()
     .defaultHeader("Authorization", headerValue)
     .defaultHeader("accept","application/json, text/event-stream")
	 .defaultHeader("Content-Type","application/json");
     return WebClientStreamableHttpTransport
	   .builder(webClientBuilder)
	   .endpoint(MCP_SERVER_ENDPOINT).build();
}

We first construct the MCP_SERVER_ENDPOINT URL from the in application.properties configured AgentCore Runtime ID. In the next article, I’ll add the use case to also add the AgentCore Gateway URL. After it, we create the WebClientBuilder by passing some HTTP headers, including the bearer token. When we create WebClientStreamableHttpTransport and set the web client builder and the MCP server endpoint. It’s important to use the HTTP Streamable web client because AgentCore Runtime (and Gateway) only supports it.

Now we are ready to initialize our MCP client and obtain the list of tools from it:

client.initialize();
var toolsResult = client.listTools(); 
for (var tool : toolsResult.block().tools()) { 
    logger.info("tool found " + tool); 
}

We get all 4 tools that our Conference Search application from part 2 exposes, which we deployed on AgentCore Runtime.

Next, we need to create the list of tool callbacks from MCP Client to pass to the ChatClient:

var asyncMcpToolCallbackProvider = AsyncMcpToolCallbackProvider.builder()
     .mcpClients(client)
     .build();

If you don’t need all the tools, you can filter them and, for example, only leave those tools whose name contains Conference_Search_Tool_By_Topic as a substring, as shown below:

var asyncMcpToolCallbackProvider = 
AsyncMcpToolCallbackProvider.builder().mcpClients(client)
  .toolFilter(new McpToolFilter() {				 
       @Override public boolean test(McpConnectionInfo info, Tool tool) { 
	    return tool.name().toLowerCase()
                .contains("Conference_Search_Tool_By_Topic"); 
             } 
         }
      )
    .build();

Next, to enable search prompts such as “Please provide me with the list of conferences including their IDs, with Java topic happening in 2027, with call for papers open today”, we need to obtain the current date. LLM doesn’t know the current date, and for this, I wrote a small tool with the name DateTimeTools :

@Tool(description = "Get the current date ")
String getLocalDate() {
    return LocalDate.now().toString();       
 }

It contains only one tool to get the current date. Then, we pass this local tool to the ChatClient by invoking the tools method. We also pass the tool callback list from the AsyncMcpToolCallbackProvider by invoking the toolCallbacks method. The last step is to use the ChatClient with the given prompt and tool (callbacks) to produce an answer to the prompt. This answer will be streamed back to the user:

  return this.chatClient.prompt().user(prompt)	
      .tools(new DateTimeTools())
	  .toolCallbacks(syncMcpToolCallbackProvider.getToolCallbacks())
      .stream()
      .content();

Build, deploy, and test the local Conference Application MCP client

Let’s build our application with: mvn clean package and start it with: mvn spring-boot:run.

Now we can use CURL or HTTPie to send some prompts. For example:

“Please provide me with the list of conferences, including their IDs, with Java topics happening in 2027”.

Here is an example of the request with HTTPie:

http GET http://localhost:8080/conference?prompt=”Please provide me with the list of conferences, including their IDs, with Java topics happening in 2027″ Content-Type:text/plain.

Here is the correct LLM response:

As you can see from the description and logs, LLM used the tool Conference_Search_Tool_By_Topic_And_Date from the MCP server to produce the answer. Let’s try another prompt:

http GET http://localhost:8080/conference?prompt=”Please provide me with the list of conferences, including their IDs, with Java topics happening in 2026 and 2027, with the call for papers open today” Content-Type:text/plain

Here is the correct LLM response again:

As you can see from the description and logs, LLM used the tools to produce the answer. Conference_Search_Tool_By_Topic_Date_CFP_Open from the MCP server and the local tool Get_The_Current _Date to produce the answer.

Conclusion

In this article, we developed the (MCP-) client, capable of talking to our application running on AgentCore Runtime. In the next article, we’ll look at another alternative to AgentCore Runtime to host MCP servers on AgentCore – AgentCore Gateway. We’ll also compare both alternatives. In one of the next articles, I’ll show you how to deploy and run this MCP client on the AgentCore Runtime as well, using the HTTP protocol. It’s not always appropriate to work with the client locally.