A Deep Dive into MCP Client Interactions in TypeScript

This article is part of a series on building MCP clients in TypeScript, using a custom client to illustrate the process. In this guide, we'll explore how to interact with tools and resources within our MCP Hub class and manage connection handling.

Introducing the MCP Inspector

Before diving into the code, it's helpful to introduce the methods using the MCP Inspector. According to its documentation, the MCP Inspector is an interactive developer tool designed for testing and debugging MCP servers.

While a full tutorial on the inspector is beyond this article's scope, we'll touch on its usage. For instance, when launching the inspector, you might specify a client port like 8080, though this isn't a required standard. Once launched, it presents a user-friendly interface for debugging.

To demonstrate, we'll use the command and arguments for the 'everything server,' which is configured in the Source book mCP config.js file. The 'everything server' is a test server from the Model Context Protocol that emits various types of output, covering nearly every possible MCP message. Let's connect to it.

Once connected, the inspector's UI displays several data sources in its navigation bar, including Resources, Prompts, and Tools. The interface provides options to list the available data for each type:

• List Resources
• List Resource Templates
• List Prompts
• List Tools

For example, selecting List Tools displays a list of available tools along with their input schemas. The inspector also provides an interface on the right-hand side to execute these tools directly.

This context from the inspector helps clarify the purpose of the methods in our code, such as listTools, listResources, and listResourceTemplates.

Calling a Tool with callTool

The callTool function accepts serverName, tool, and params as arguments. It returns a promise resolving to a Zod-inferred type of callToolResultSchema.

Note: The type definitions, like callToolResultSchema, originate from a comprehensive types.d.ts file that contains all the necessary type definitions for the Model Context Protocol. Any methods that appear hardcoded are defined within this file.

The function operates as follows:

1. It retrieves the connection object from a connections map using the serverName.
2. If the server isn't recognized or connected, it throws an error.
3. It then calls the tools.call endpoint, passing the tool and params arguments.
4. Finally, it validates the response against the callToolResultSchema.

Listing Available Resources and Tools

The various list functions share a similar structure. Let's begin with listTools.

This function takes serverName as an argument and returns a promise with a Zod-inferred type of listToolsResultSchema. It starts by retrieving the server connection from the connections map defined at the top of the MCP Hub class.

The implementation includes several key checks:

• Guard Clauses: A guard clause checks if the connection is missing or disconnected and throws an error accordingly.
• Capability Check: It verifies if the selected server supports tools. If not (e.g., it only supports resources), it logs a warning message.
• Timeout Handling: A 5-second timeout is implemented using an AbortController. The timeout is cleared upon a successful response or an error.
• Response Handling: If the request is successful, it validates the response against listToolsResultSchema and returns it. In case of a timeout or a general error, it clears the timeout and throws an appropriate error. If all else fails, it returns an empty array.

The listResources Method

The listResources method follows a nearly identical pattern, with the notable exception of timeout handling in this particular implementation. It retrieves the connection, includes a guard clause for missing servers, and checks if the server supports resources. The request is made to the resources/list endpoint, and the response is validated against the listResourcesResultSchema.

It returns the response or an empty array on success. If a 'Method Not Found' response is received, it throws a warning; otherwise, it throws a generic error. As a fallback, it returns an empty array.

The listResourceTemplates Method

Similarly, the listResourceTemplates method follows the same logic, targeting the resources/templates/list endpoint and validating against the listResourceTemplatesResultSchema.

Managing Connections

To conclude the overview of the MCP Hub class, let's examine the methods for managing connections.

listConnections: This straightforward method returns an array of objects derived from the connections map. Each object contains properties for serverName, connected status, capabilities, and an optional error message.

getConnection: This function accepts a serverName and returns the specific connection information for that server from the map.