Recommended resources
The freely available resources this lesson will direct you to.
Hello! In our last lesson, you successfully built a dynamic MCP server capable of serving content from a local file. This was a major step, but a server is only useful if a client can connect to it. Today, we will complete the circuit by configuring a host application to use the server you built.
This lesson directly addresses your goal of building end-to-end AI systems. You'll see how the different components—the AI model, the application it lives in, and the external context server—all come together. We will explore two approaches: first, connecting your server to an existing AI-powered application, and second, outlining how to build your own custom client application from scratch.
By the end of this lesson, you will have connected your dynamic MCP server to an LLM, enabling it to answer questions using the live data your server provides.
The Full Picture: Host, Client, and Server
Before we dive into the implementation, let's clarify the roles of each component in the Model Context Protocol architecture. So far, we've focused entirely on the MCP Server, the program that exposes tools and resources.
Now, we introduce the other two key players:
- The Host: This is the primary application that a user interacts with. It could be an IDE like VS Code or Cursor, a chat application like Claude Desktop, or a custom backend service you build yourself. The Host's job is to manage the user interaction and orchestrate the communication with the LLM.
- The MCP Client: This is a component that lives inside the Host application. Its specific role is to communicate with one or more MCP Servers using the standardized protocol. It discovers available tools and resources from the server and executes calls to them on behalf of the LLM.
The diagram below illustrates this relationship. The Host application (containing the AI and MCP Client) makes a request, which the MCP Server fulfills by fetching data from a source.
The interaction for a single user query typically follows these steps:
- The user sends a prompt to the LLM within the Host application.
- The Host's MCP Client has already connected to your server and knows which tools/resources are available.
- The Host sends the user's prompt and the definitions of the available tools to the LLM.
- The LLM analyzes the prompt and decides if it needs to use one of the tools to answer the question.
- If yes, the LLM responds with a "tool use" request.
- The MCP Client receives this request and makes the actual call to your MCP Server.
- Your server executes the logic (e.g., reads the
context.txtfile) and returns the data. - The MCP Client passes this data back to the LLM, which then formulates the final, context-aware response for the user.
Part 1: Configuring an Existing Host (Cursor IDE)
The most straightforward way to see this in action is to connect your server to an existing, MCP-aware application. We'll use Cursor, an AI-native code editor built on top of VS Code. Since you're an experienced software engineer, the environment will feel very familiar.
The following article from Real Python provides an excellent, detailed walkthrough of setting up an MCP server in Cursor. We will follow its steps to connect the Node.js server you built in the previous lessons.
Python MCP Server: Connect LLMs to Your Data
This article provides a fantastic, step-by-step guide with screenshots for configuring Cursor to connect to a custom MCP server. Although the article uses a Python server, the steps for configuring Cursor are identical for our Node.js server.
Please download and install Cursor first. Then, read the section Setting Up Cursor and follow the instructions to add your server. When you get to the JSON configuration step, use a configuration like the one below, making sure to replace the path in args with the absolute path to your server's compiled index.js file.
json
{
"mcpServers": {
"my-dynamic-server": {
"command": "node",
"args": [
"/path/to/your/project/build/index.js"
],
"description": "A server that can read content from a local file named context.txt"
}
}
}
After configuring and verifying the connection (you should see a green light next to your server name in Cursor's settings), proceed to the next section of the article, <tf start="Using Your MCP Server in Cursor" end="to develop with MCP.">Using Your MCP Server</tf>. Try asking the chat a question that would require it to use your server, for example: "What are the contents of the local file context?"
You should see the LLM request permission to run the `local-file-context` resource, after which it will display the contents of your `context.txt` file. You have now successfully configured a host application and connected an LLM client!
Part 2: Building a Custom Client Application
Using a pre-built host like Cursor is excellent for many use cases, but as an AI engineer building scalable systems, you will often need to create your own custom host applications. This could be a backend for a web app, a data processing pipeline, or a standalone agent.
Let's walk through how you would build a simple command-line client that connects to your server. The official MCP documentation provides a complete guide for this. Since you are proficient in JavaScript and built your server in TypeScript, we'll focus on the TypeScript client example. The principles are identical across languages like Python or Go.
The process involves programmatically doing what Cursor's UI did for us:
- Specifying the command to run the server.
- Establishing a client session over
stdio. - Listing the available tools/resources.
- Creating a loop to pass user queries and tool definitions to an LLM.
- Handling tool calls from the LLM by executing them via the client session.
The official documentation provides boilerplate code to create a fully functional, command-line MCP client. We will examine the TypeScript implementation.
Please review the TypeScript section of the guide. Start from Setting Up Your Environment to prepare your project. Then, carefully study the code in the Creating the Client section. Pay close attention to these key methods: connectToServer(): This is where you programmatically define how to start your server. Note the StdioClientTransport which takes a command and args, just like the JSON in Cursor. processQuery(): This is the core logic. It sends the user query and the list of tools to the LLM, checks if the LLM wants to use a tool (tool_use), and if so, calls this.mcp.callTool(). It then sends the result back to the LLM to get a final answer. Finally, review the Main Entry Point and Running the Client sections to understand how the application is executed and tied together. You can adapt this code to connect to the Node.js server you've already built.
While the manual implementation above gives you full control, many high-level AI frameworks are starting to provide built-in support for MCP, simplifying this process significantly. For example, LlamaIndex offers abstractions that handle the connection and tool-wrapping for you.
To see what this looks like in practice, watch this short clip.
MCP meets Ollama: Build a 100% local MCP client
This video demonstrates how to use LlamaIndex's native MCP support to connect to a server. This is a powerful pattern for building more complex agentic systems.
Watch the segment from this clip. The speaker shows how BasicMCPClient is used to establish the connection to the server URL, and MCPToolSpec automatically fetches the tools and converts them into a format that a LlamaIndex agent can use. This abstracts away much of the boilerplate code we saw in the manual implementation.
Conclusion
In this lesson, you bridged the final gap in the MCP architecture by connecting a host application and an LLM client to your dynamic server. You've seen both how to configure a powerful existing tool like Cursor and how to build your own custom client application from scratch.
Key Takeaways:
- Host & Client Roles: The host is the user-facing application, while the MCP client is the specific component within it that communicates with MCP servers.
- Configuration is Key: You must configure the client with the necessary information (command, arguments, URL) to find and run the server process. This can be done via a UI (like in Cursor) or programmatically in code.
- The LLM is the Decision-Maker: The core of the interaction relies on the LLM deciding when to use a tool based on the user's query and the tool descriptions provided by your server.
- Frameworks Simplify Integration: High-level frameworks like LlamaIndex are increasingly offering built-in MCP support, which can significantly accelerate development for complex applications.
You now have a complete, end-to-end system where an LLM can dynamically pull context from your local environment. However, in any real-world application, you can't just allow anyone to access your data. In our next and final lesson on MCP, we will tackle the critical topic of security and access control, ensuring that only authorized clients can interact with your server.