Practical MCP with FastMCP & LangChain

Testing The Server

After starting the server, you can test it by sending a request using curl or any HTTP client. The following request initializes the MCP connection by sending an initialize request to the server:

curl -i -X POST http://127.0.0.1:8000/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{
    "jsonrpc": "2.0",
    "id": 0,
    "method": "initialize",
    "params": {
      "protocolVersion": "2025-11-25",
      "capabilities": {},
      "clientInfo": { "name": "curl", "version": "0.1" }
    }
  }'

Our request follows the JSON-RPC 2.0 format. As a reminder, a valid initialization request must include the following fields:

• jsonrpc: The protocol version. This must always be "2.0".

• id: A unique identifier for the request. It can be a string or a number and is used to match the response to the request. (Requests that expect a response must include an id.)

• method: The name of the method to invoke.

• params: An object or array containing the parameters for the method.

Now, the server will respond to the initialization request with a message similar to this:

HTTP/1.1 200 OK
mcp-session-id: c82aca78fcdd4d6f9917f51251272ca6
// [other headers...]

event: message
data: {
  "jsonrpc": "2.0",
  "id": 0,
  "result": {
    "protocolVersion": "2025-11-25",
    "capabilities": {
      "experimental": {},
      "prompts": {
        "listChanged": false
      },
      "resources": {
        "subscribe": false,
        "listChanged": false
      },
      "tools": {
        "listChanged": false
      }
    },
    "serverInfo": {
      "name": "Calculator Server",
      "version": "1.26.0"
    }
  }
}

The event: message line means the response is sent as a Server-Sent Event (SSE) with the event type "message".

The actual JSON-RPC response is inside the data: payload and includes the following fields:

• jsonrpc: The JSON-RPC version. This should be "2.0".
• id: The same request identifier you sent in initialize, so the client can match the response.

• result: The successful response payload. It contains:

• protocolVersion: The MCP protocol version the server selected for this session.

• capabilities: What the server supports. Our server has no capabilities yet but it still needs to include this field in the response. The capabilities could include:

  • tools.listChanged: whether the server can notify the client if the tool list changes.
  • resources.subscribe: whether the server supports subscribing to resource updates.
  • resources.listChanged and prompts.listChanged: whether the server can notify the client when those lists change
  • And more.

• serverInfo: Basic information about the server implementation (name and version)

Note that the server also includes a custom header MCP-Session-Id in the response. This is a unique identifier for the MCP session that was just initialized. The client must include this session ID in the MCP-Session-Id header of all subsequent requests to associate them with the correct session on the server.

Let's export it as an environment variable for easier use in future requests:

export MCP_SESSION_ID