MCP-powered assistant

What you'll build

Step-by-step build

1. 1

   Connect to one server as a client

   Use the MCP SDK client to connect to a single server and list its tools. Getting one connection solid first keeps the multi-server step from being a debugging maze. Print the discovered tools to confirm the handshake works.

2. 2

   Connect to several servers

   Extend the client to open connections to two or more servers at startup and keep them alive. Track which server each connection belongs to. Managing multiple live connections cleanly is the foundation of the whole assistant.

3. 3

   Merge tools into one set

   Collect the tools from every connected server into a single list, tagging each with its origin server. Namespacing prevents two servers with a similarly named tool from colliding. This merged set is what you will hand to the model.

4. 4

   Expose the tools to the model

   Convert the merged MCP tools into the format the Vercel AI SDK expects so the model can call them. Now the model sees all servers' capabilities as one toolbox. Confirm it can call a tool from each server.

5. 5

   Route requests to the right tool

   Let the model choose which tool fits a request, then dispatch the call to the server that owns it. Routing, picking the right tool from the right server, is the core skill of this project. Log the chosen server and tool for every call.

6. 6

   Build the chat loop

   Wrap it in a chat loop so a single request can trigger several tool calls before the assistant answers. Feed each tool result back so the model can decide the next step. This is what makes the assistant feel capable rather than one-shot.

7. 7

   Handle a server going down

   Detect when a server fails to connect or a call errors, and continue with the remaining servers instead of crashing. Tell the user which capability is unavailable. Resilience is what makes a multi-server assistant usable in the real world.

8. 8

   Surface the routing in the UI

   Show, per request, which server and tool were used. This transparency makes the assistant debuggable and demonstrable. It also proves the routing is actually working rather than guessed.

Done when

• ✓The assistant connects to at least two servers and merges their tools
• ✓A request that needs a specific server is routed to the correct tool
• ✓One request can chain several tool calls before answering
• ✓If a server is down, the assistant keeps working with the rest
• ✓The UI shows which server and tool handled each request

Ship it

Deploy the Next.js app to Vercel free tier with the MCP connections held in the server route. Keep the Groq key and any server credentials in environment variables. Write a README listing the connected servers, an example multi-tool request, and how to add another server.

What it proves: Shows you can build the client side of MCP: aggregating many servers and routing each request to the right tool, the pattern behind capable assistants.

Paste this into Cursor, Claude, or ChatGPT and build it step by step.

You are my senior AI engineer pair. Help me build "MCP-powered assistant" step by step. MCP is the Model Context Protocol; here I am building the client side. Routing means the model picks the right tool from the right connected server for each request, and tool-calling means it asks to run a tool and I dispatch it to the owning server.

Stack: the MCP SDK client to connect to multiple servers, Vercel AI SDK 6 to expose their tools to the model, Groq API for inference, Next.js for the chat UI and server route, plus two MCP servers (one I built and one public).

Requirements:
1. Connect to two or more MCP servers at startup and keep connections alive.
2. Merge their tools into one namespaced set.
3. Let the model route each request to the correct tool and server.
4. Support a chat loop where one request chains several tool calls.
5. Handle a server being down without crashing, and show which server and tool handled each request.

Work in this order: connect one server, then several, then merge tools, then expose to the model, then routing, then the chat loop, then failure handling, then the UI. Give me commands and code for each step and STOP after each so I can test. Do not write the whole app at once.