Make Your Agent Ask for Input

Build an MCP agent that pauses for your answer before finishing a task.

Introduction

30 Second Summary

An assistant can move quickly until your request leaves out one important detail. A confident guess can send the whole task in the wrong direction.

In this project, you will build a local MCP server with a tool that connects to an AI agent. You will use elicitation to turn a missing detail into a visible pause that resumes with your answer.

What You'll Build

Your terminal shows an agent pausing for a missing value before completing its response with the answer you provide.

By the end of this project, you'll have:

  • A discoverable local toolset where your client lists the available tool from one server. It later shows both tool sets after you connect a second server.
  • A working agent connection that calls the matching server tool. You see the result printed for your request.
  • A visible elicitation pause where the terminal waits for a missing value. Your answer resumes the same run. The final response reflects your input.
  • Secret Mission: An optional challenge to push your skills further.

Are there any prerequisites?

You need Python, a terminal, and a model API key. Everything runs locally, so you do not need hosting.

Before We Start

A mid-run question only works when the local server and the agent understand the same protocol. This setup gives both sides a shared foundation before you write either file.

Python provides the runtime for both local programs. Its pip package manager installs the libraries.

Model Context Protocol (MCP) support lets the server request missing input. LangChain connects the tool to your agent.

FastMCP handles the protocol connection. LangGraph preserves the paused run while you answer.

In this step, get ready to:
  • Confirm that Python and pip are available.
  • Install MCP support and the agent runtime.
  • Verify that the development environment is ready.
Check Python and pip

LangChain requires Python 3.10 or higher. The official Python installers also include pip.

  • Press Cmd+Space (macOS) or the Windows key (Windows) to open your search bar.
  • Type Terminal (macOS) or PowerShell (Windows) and press Enter to open it.

macOS

  • Check your installed Python version by running this command:
python3 --version

What does this check?

The command asks your terminal which Python 3 runtime it can access. The reported version determines whether your environment supports LangChain.

  • Check that the matching pip package manager is available by running this command:
python3 -m pip --version

Why check pip this way?

Running pip through python3 confirms which Python installation owns the package manager. This keeps the runtime and its libraries aligned.

Windows

  • Check your installed Python version by running this command:
python --version

What does this check?

The command asks PowerShell which Python runtime it can access. The reported version determines whether your environment supports LangChain.

  • Check that the matching pip package manager is available by running this command:
py -m pip --version

Why check pip this way?

The Python launcher runs pip through your installed runtime. This confirms that the package manager belongs to the Python installation you plan to use.

Choose the tab that matches the output in your terminal.

✔️ I see the required Python version

Your Python version meets the 3.10 minimum. Your package manager is ready for the project libraries.

ⓧ I see an older version

Your terminal can reach Python, but that runtime is too old for the current LangChain packages. Install the latest stable Python release before continuing.

macOS

  • Download the latest stable installer from the official Python releases for macOS page.
  • Run the downloaded installer using its default selections.
  • Close Terminal after the installation finishes.
  • Reopen Terminal through the macOS search bar.
  • Confirm the new Python version by running this command:
python3 --version
What confirms the upgrade?

The command should now report Python 3.10 or higher. The new terminal session picks up the runtime installed from Python.org.

Windows

  • Download the latest stable installer from the official Python releases for Windows page.
  • Run the downloaded installer using its default selections.
  • Close PowerShell after the installation finishes.
  • Reopen PowerShell through the Windows search bar.
  • Confirm the new Python version by running this command:
python --version
What confirms the upgrade?

The command should now report Python 3.10 or higher. The new PowerShell session picks up the newly installed runtime.

ⓧ The command is not found

Your terminal cannot find a Python runtime yet. Install the latest stable release from Python.org.

macOS

  • Download the latest stable installer from the official Python releases for macOS page.
  • Run the downloaded installer using its default selections.
  • Close Terminal after the installation finishes.
  • Reopen Terminal through the macOS search bar.
  • Confirm that Python is available by running this command:
python3 --version
What confirms the installation?

The command should report Python 3.10 or higher. This proves that Terminal can reach the installed runtime.

Windows

  • Download the latest stable installer from the official Python releases for Windows page.
  • Run the downloaded installer using its default selections.
  • Close PowerShell after the installation finishes.
  • Reopen PowerShell through the Windows search bar.
  • Confirm that Python is available by running this command:
python --version
What confirms the installation?

The command should report Python 3.10 or higher. This proves that PowerShell can reach the installed runtime.

Install MCP and agent support

The langchain[mcp] package adds LangChain's MCP integration. It pulls in the protocol support needed for elicitation.

  • Install MCP support and the agent runtime by running this command:
pip install "langchain[mcp]"

What does this install?

  • The langchain[mcp] extra installs LangChain with its MCP integration.
  • FastMCP supplies protocol negotiation and connection management.
  • LangGraph supplies the interrupt mechanism that holds a paused agent run.

Seeing an install error?

  • Confirm that the Python version shown earlier is 3.10 or higher.
  • Return to the matching Python outcome tab if your terminal cannot find pip.
  • Copy the final lines of the terminal output before asking for help.

Help me troubleshoot this LangChain MCP installation error. You can also share the same terminal output with the NextWork community.

Verify the development environment

Before you run the final check, which packages do you expect to find in the installed package list?

  • Display the installed packages by running this command:
pip list

What does this prove?

The package list shows what your current Python environment can import. Finding the MCP and agent libraries here confirms that both sides of the project have their required foundations.

You should see langchain, fastmcp, and langgraph in the output. That is the foundation in place: your machine can build the server and preserve an interrupted agent run.

✔️ Awesome, I've got everything!

Your local development environment is ready. No project files or server processes exist yet.

ⓧ I'd like to double check the full code

There is no project code to compare yet. Your completed setup should match this state:

  • Terminal access is ready.
  • Python 3.10 or higher is installed.
  • The pip package manager is available.
  • FastMCP is installed with elicitation support.
  • LangChain is installed as the agent SDK.
  • LangGraph is installed as the agent runtime.
  • No project files have been created.
  • No local server is running.

Your local toolchain is ready. Next up, you will run a small MCP server and discover its tool from a client.

Run and Inspect Your MCP Server

Before an agent can use a tool, the server must publish that tool through a connection the client can reach. This step proves that connection works before an agent enters the picture.

You will create a local Model Context Protocol (MCP) server with FastMCP. You will start it over HTTP and inspect its tool list from a separate client.

In this step, get ready to:
  • Create a local MCP server with one tool.
  • Start the server over HTTP.
  • Connect an MCP client and retrieve the tool list.
Create the server and its first tool

A FastMCP server publishes Python functions as tools. The first version of your greet() tool returns a result without asking a follow-up question.

  • Switch back to the terminal from your prepared development environment.
  • Move to your Desktop by running this command:
cd ~/Desktop

Why start on your Desktop?

Starting from your Desktop gives the server script a predictable location. You can find the file again when you extend it later.

  • Create my_server.py by running the block below:
cat > my_server.py <<'PY'
from fastmcp import FastMCP

# Create a server that publishes one simple tool
mcp = FastMCP("My MCP Server")

@mcp.tool
def greet(name: str) -> str:
    """Return a greeting without requesting more information."""
    return f"Hello, {name}!"

if __name__ == "__main__":
    # Use HTTP so a separate client can connect
    mcp.run(transport="http", port=8000)
PY

What does this code do?

  • The FastMCP instance represents your local MCP server.
  • The @mcp.tool decorator publishes greet() to connected clients.
  • The greet() function accepts a name with the original request. It returns the greeting immediately.
  • The mcp.run() call exposes the server through an HTTP endpoint on port 8000.
  • Confirm that the server script exists by running:
ls

What does this check prove?

The ls command lists the files in your current location. Seeing my_server.py confirms that the shell saved your server script on the Desktop.

You should see my_server.py in the output.

Server file missing?

Check that the file-creation block ended with a line containing only PY. The shell needs that closing line before it saves the file.

Run the Desktop navigation command again if the file was created in a different location.

Help me find or recreate my MCP server script.

✔️ Awesome, I've got everything!

Great. Your my_server.py file now contains one published tool and an HTTP server entry point.

ⓧ I'd like to double check the full code

Compare your saved my_server.py file with this complete version.

from fastmcp import FastMCP

# Create a server that publishes one simple tool
mcp = FastMCP("My MCP Server")

@mcp.tool
def greet(name: str) -> str:
    """Return a greeting without requesting more information."""
    return f"Hello, {name}!"

if __name__ == "__main__":
    # Use HTTP so a separate client can connect
    mcp.run(transport="http", port=8000)
Start the local MCP server

An HTTP server keeps running while clients connect to it. The command occupies this terminal until you stop the process.

  • Start the server by running:
python my_server.py

What does this command do?

Python executes my_server.py. FastMCP keeps the process running so clients can reach the MCP endpoint.

Your local server is now live. The terminal remains occupied while the server listens at http://localhost:8000/mcp.

Server not staying active?

Confirm that you are running the command from the Desktop where my_server.py was created.

If Python cannot load FastMCP, confirm that the prepared development environment from earlier is active.

Help me start my local FastMCP server.

List the tool from an MCP client

The server decides which tools exist. A client discovers those tools by requesting the server's current catalog.

  • Create a second terminal session using your terminal application's new-tab control.

Before you run the client, do you expect it to find zero tools or one tool?

  • Connect to the running server and request its tool list by running:
fastmcp list http://localhost:8000/mcp

What does this command prove?

The fastmcp CLI acts as an MCP client. It connects to the live endpoint and asks the server which tools it exposes.

You should see a single tool named greet with its name parameter. That result proves the client reached the running server and retrieved its published catalog.

Tool list not appearing?

Return to the first terminal and confirm that the server process is still running.

Check that the client command uses the same port as mcp.run() in my_server.py.

Help me connect the FastMCP client to my local server.

You now have a running MCP server and proof that a client can discover its tool. Next, you will connect an agent and watch it choose that tool during a request.

Connect Your Agent to the Tool

Your local MCP server already proves that a client can discover its single tool. The next gap is letting an agent use that tool from a request.

An agent runtime turns the discovered tool list into actions the model can select. This connection gives the agent a way to act on your request.

You will create a small agent script that uses the running server. One tool-backed request will prove the full path works.

In this step, get ready to:
  • Create an agent script that connects to the primary local server.
  • Supply the discovered tool to the agent.
  • Run a request that requires the tool.
Build the agent path

The working client already knows how to reach the primary server. Reusing that connection keeps this script focused on tool selection.

How Does the Agent Path Work?

  • The connection points to the same primary local server as the working client.
  • Tool discovery retrieves the server's available tool.
  • The agent receives that discovered tool as an available action.
  • The request matches the capability described by the tool.
  • The script prints the result returned after the tool call.
  • Return to the development environment from earlier.
  • Use your editor's new-file control to build the agent script beside the existing server script.
  • Save the agent script.
  • Confirm your editor's file tree now shows the server script plus the agent script.

You should now see two small scripts beside each other. The server owns the tool while the agent owns the request.

Run the tool-backed request

The request should depend on the capability shown in the tool description from the previous step. This gives the agent a clear reason to select the server's tool.

Before you run the agent, do you think it can complete the request without calling the tool?

  • Keep the primary MCP server running in its terminal.
  • Return to the terminal where you ran the working client.
  • Run the new agent script with the same runtime command pattern you used for the client.

You should see the agent select the server's single tool for the request.

You should then see the returned tool result printed as the final output.

That proves the full connection works. Your agent can now discover a local tool and use it to complete a request.

Agent Not Reaching the Tool?

  • Confirm the primary server is still running in its original terminal.
  • Check that the agent script uses the same primary server target as the working client.
  • Check that tool discovery finishes before the agent receives the request.
  • Check that the discovered tool is supplied to the agent runtime.

Share the output you see with help me trace why my agent is not calling the discovered MCP tool.

Your agent can now discover the server's tool and call it for a matching request. Next, you will make that tool pause when it needs information from you.

Add an Elicitation Question

Your agent already reaches the local tool and prints its result. The tool still fills in missing information by itself, so the run can finish with a guess.

An MCP elicitation request hands that missing value to you. You will update both scripts so the same run can pause while it waits.

In this step, get ready to:
  • Update the server tool to request a missing value.
  • Prepare the agent to preserve a paused run.
  • Run the agent to see the elicitation question.
Update the tool to request missing input

The registered tool currently supplies every value needed to produce its result. Its missing-value path now needs to ask you for that information before it can finish.

  • Switch back to the MCP server script from earlier.
  • Locate the registered tool that currently returns a result without requesting user input.
  • Replace the fallback with a complete elicitation flow that asks for the required value before feeding the accepted response into the existing result.
  • Save the MCP server script.
  • Return to the terminal running the primary MCP server.
  • Stop the existing server process using your terminal's interrupt control.
  • Restart the primary MCP server using the same command from earlier.
  • Repeat the client tool-listing check from earlier.

You should see the primary server return to its running state. The tool listing should still show its single registered tool.

Why must the tool wait?

The elicitation request suspends the tool's result path at the point where information is missing. The accepted response supplies the value needed by that same path.

Keeping the request inside the tool prevents the agent from inventing a replacement. The question appears exactly where the missing information matters.

Server not returning to its running state?

  • Confirm that you saved the updated MCP server script before restarting the process.
  • Check that the elicitation request sits inside the registered tool's missing-value path.
  • Compare the request structure with the elicitation support in your installed MCP SDK.

Ask for help with the server update.

Prepare the agent to preserve the run

A paused tool call needs its active run state when your answer arrives. The agent's elicitation handler keeps that state available until the run resumes.

What must the handler preserve?

  • The incoming question appears in the terminal.
  • The active tool invocation remains available while the agent waits.
  • The user's reply returns to the same invocation.
  • The existing result output runs after execution resumes.
  • Switch back to the agent script from earlier.
  • Locate the path that invokes the discovered tool before printing its result.
  • Replace the invocation wrapper with a complete elicitation handler for the pause-to-resume lifecycle described above.
  • Save the agent script.

✔️ Both scripts are ready

The server script can request missing input. The agent script can retain the active run until that input arrives.

ⓧ I'd like to double check the full code

The complete scripts should now have these responsibilities:

  • The server script starts the primary local MCP server.
  • The server registers one elicitation-enabled tool.
  • The tool requests its missing value before completing the result.
  • The agent script connects to the primary local MCP server.
  • The agent discovers the server's single tool before submitting the existing request.
  • The elicitation handler displays the incoming question.
  • The handler preserves the active run while it waits for the user's reply.
  • The handler sends the reply back to the same run.
  • The existing result output runs after execution resumes.
Trigger the elicitation pause

The next run reaches the newly added request using the same task as before. This check reveals whether the agent keeps the missing value in your hands.

  • Return to the terminal used for the earlier agent runs.
  • Confirm that the existing agent request still omits the value your tool now requests.

Before you start the run, do you think the agent will finish the task or wait for you?

  • Start a fresh agent run by repeating the same command from earlier.

You should see the tool's question in the terminal. The process remains active while it waits for your input.

The completed result should remain absent. That visible pause proves the tool has stopped guessing.

  • Leave the elicitation question unanswered for the next step.

Agent finishing without a question?

  • Restart the primary MCP server if it is still running the previous tool implementation.
  • Check that the tool reaches its elicitation request before building the result.
  • Remove any broad error handling that converts the pause into a normal result.

Ask for help tracing the missing pause.

You did it. Your agent now stops at the missing value instead of completing the task with a guess.

Next, you will answer the question and resume the same run through to its final response.

Answer and Resume the Agent Run

Your previous agent run reached the question from the primary MCP server's elicitation request. The run is paused with its context intact.

That pause gives you control over the missing value. Your answer lets the same tool call finish without starting the job again.

In this step, get ready to:
  • Supply a concrete value for the displayed question.
  • Resume the paused agent run with your answer.
  • Confirm the final response was built from the supplied value.
Answer the displayed question

An elicitation response becomes input to the paused tool call. The agent can continue from the point where it stopped.

  • Switch back to the terminal showing the paused agent run from the previous step.
  • Read the displayed question to identify the missing value.
  • Choose a concrete value that directly answers that question.

Before you submit it, do you expect the existing run to continue or start over?

  • Type your chosen value at the waiting input prompt.
  • Press Enter to submit the answer.

You should see the paused run continue. The tool should finish before the agent prints a final response.

You just completed the full elicitation loop. The agent waited for your input before completing the original request.

Run still paused?

If the terminal remains paused, click inside the active input prompt. Type your value again before pressing Enter.

If the process ended before accepting your answer, recreate the paused run from the previous step. Submit the value while that run is waiting.

Help me resume my paused agent run.

Confirm the answer shaped the result

Resuming proves the paused state was preserved. The stronger check is whether the final response carries the value you supplied.

Before you inspect the response closely, which detail do you expect to match the value you entered?

  • Locate the final response printed after the tool completes.
  • Find the detail that came from your supplied value.
  • Compare that detail with the value you entered.

You should see your value quoted directly or clearly reflected in the result. This proves the resumed tool call used your answer.

Your agent now pauses for missing information. It resumes from your answer. Next up, you will connect a second server. You will confirm the agent picks the right tool for each request.

Connect a Second MCP Server

Your primary MCP server now pauses the agent through elicitation. The resumed run proves the answer can travel back into the tool.

A multi-server agent needs one combined view of every available tool. You will connect a second server before checking whether the request reaches the right tool.

In this step, get ready to:
  • Make a second MCP server available with a distinct tool set.
  • Connect the agent to both servers in one run.
  • Route a request to the appropriate tool.
Make the second tool set available

Each MCP server exposes its own tool catalog. Distinct tool purposes make the agent's routing choice visible.

  • Leave the primary server process running in its current terminal.
  • Open a separate terminal panel with the same method you used earlier.
  • Start the second MCP server with that server's launch command.
  • Check the second server's startup output for a ready state.

You should now have two server processes available at the same time. Each server provides its own set of tools.

Why use separate servers?

Each server owns its own tool catalog. Two available servers let one client discover both catalogs during the same run.

The primary server keeps its elicitation-enabled tool. The second server expands the agent's choices without replacing the pause-and-resume flow.

List tools from both servers

The agent needs both connection definitions before discovery can reach both servers. Its existing discovery flow can then collect the available tools in one run.

  • Switch back to the agent script from earlier.
  • Add the second server's connection details beside the primary server's existing connection.
  • Save the agent script.

Before you run it, picture the two tool sets you expect the discovery output to contain.

  • Run the agent script with the same command you used earlier.

You should see the primary server's tool plus the second server's distinct tools in the same output. The tool descriptions should cover different jobs.

Only seeing one tool set?

Verify that the second server process is still running. Compare its connection details with the second connection in the agent script.

If both listings show the same tools, confirm that the second connection does not point back to the primary server.

Ask for help with the connection configuration by sharing the redacted server settings and terminal output.

Route a request to the second server

Tool descriptions give the agent the signals it uses for routing. A request that clearly matches the second server provides a direct test of that decision.

  • Change the request in the agent script to a task that matches only the second server's tool description.
  • Save the agent script.

Before you run it, predict which server owns this request.

  • Run the agent script again with the same command.

You should see the agent select a tool from the second server. The terminal should then print the resulting response.

Agent choosing the wrong tool?

Compare the request with both tool descriptions. Make the request specific to the capability exposed only by the second server.

Confirm that discovery printed both tool sets before the agent handled the request. Missing tools leave the agent without the correct routing option.

Get help diagnosing the routing choice from your tool listing and redacted run output.

That completes the multi-server flow. Your agent can now discover two tool catalogs before selecting the one that fits the request.

Secret mission

Prove Cross-Server Routing

A single successful request proves only one route. Run a two-part boundary test with one request for each server. Capture evidence that the agent selects the correct tool both times.

Clean Up Your Resources

Clean Up Your Resources

Choose whether to leave your local servers available, stop them for later, or end every running process. These local processes have no ongoing hosting cost.

Resources you used:

  • Primary local MCP server process running with one elicitation-enabled tool.
  • Second MCP server process available to the agent with a distinct tool set.

Keep everything running

No action needed. Choose this if you are still testing tool selection or experimenting with elicitation.

  • Your primary local server continues accepting connections from the agent.
  • Your second server remains available with its distinct tool set.
  • Your server script and agent script remain available as two small reference files.

Pause - I'll come back to this later

Stop the running processes to free up memory while keeping your scripts ready for another session.

  • Return to the terminal running the primary local server.
  • Press Ctrl+C to stop the primary server process.
  • Return to the terminal running the second server.
  • Press Ctrl+C to stop the second server process.
  • Confirm that both terminals have returned to a command prompt.
  • Use the same start commands from the project when you want to make both servers available again.

Delete - I don't want to use this again

End every active project process. Keep the small server and agent scripts as reusable reference files.

  • Return to the terminal running the primary local server.
  • Press Ctrl+C to stop the primary server process.
  • Return to the terminal running the second server.
  • Press Ctrl+C to stop the second server process.
  • Confirm that both terminals have returned to a command prompt.
  • Close the terminal sessions after both server processes have stopped.

That completes your local cleanup. Both server processes are stopped while your two small scripts remain ready to revisit.

Nice Work!

Nice Work!

You’ve built a local MCP system where an agent can discover tools across two servers. Your agent can pause for missing information before resuming with the answer you provide.

You've learned how to:

  • Run a local MCP server with a registered tool. You also confirmed that a connected client could discover that tool.
  • Connect an agent to an MCP server and trigger a tool call. You then added elicitation so the run paused for your input before producing its final response.
  • Connect the agent to multiple MCP servers. You verified that it listed both tool sets before routing a request to the appropriate tool.
  • Secret Mission: completed an optional challenge to extend your agent’s tool-using workflow.

Ready to quiz yourself?